Hello,
I was surprised to find a heap allocation in the following function prolog:
https://gist.github.com/Julio-Guerra/a3a2088832cd927669c08e1127e4c25a
Under what circumstances is this happening and it is possible to avoid it?
Thanks,
Julio
--
You received this message because you are
On Wed, Sep 23, 2020 at 3:36 PM 'ju...@sqreen.com' via golang-nuts
wrote:
> I was surprised to find a heap allocation in the following function prolog:
> https://gist.github.com/Julio-Guerra/a3a2088832cd927669c08e1127e4c25a
I think the function prolog consists of the first three assembler
On Wed, Sep 23, 2020 at 11:25 AM Henrik Johansson
wrote:
> This is funny, why isn't there a panic in this case? It clearly "works" as
> in it doesn't deadlock or panics assuming a write lock isn't somehow mixed
> incorrectly.
>
Why would there be a panic? The behavior is well-defined and
This is funny, why isn't there a panic in this case? It clearly "works" as
in it doesn't deadlock or panics assuming a write lock isn't somehow mixed
incorrectly.
On Tue, Sep 22, 2020 at 3:56 PM 'Bryan C. Mills' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> Note that a lock on a
Thanks Ian,
The root cause of this issue is not the hard drive, it is something with
overlapped offset and high offset values, need to be set to 0 to have a
smooth APPEND to the file.
I need to use /x/sys/windows package to call this function WriteFile(handle
Handle, buf []byte, done *uint32,
Using node.js, we might have this:
const z = new Z();
exports.z = z
and then in another file we can import
import {z} from '../z'
with Golang, I am trying to do something similar:
package log
import Logger "github.com/foo/bar/logger"
// create an instance
var log = Logger.create()
//
See https://golang.org/pkg/time/#Time.Format
Here's how to use it. I think this is exactly what you want:
https://play.golang.org/p/3r0TFtOmtqF
On Wed, Sep 23, 2020 at 11:43 AM Alex Mills wrote:
> My guess, is that a starting place would be something like:
>
>
> *var s =
It works temporarily, but then I have to manually update each file that
imports + exports the methods, it won't "just work" with new versions of
the library that gets imported, right?
On Wed, Sep 23, 2020 at 11:59 AM Jason Phillips
wrote:
> Did you try your own suggestion? It seems to work
I have this date string:
"2020-09-23 18:31:41.015852841 + UTC"
the above is generated via:
*time.Now().UTC().String()*
my question is, how can I generate a date string like this:
"2020-09-23 18:31:41.0158"
and how can I then parse it? I dont need to indicate that it's UTC, I can
Did you try your own suggestion? It seems to work
fine: https://play.golang.org/p/KVo5COKj2ii
On Wednesday, September 23, 2020 at 1:46:05 PM UTC-4 al...@channelmeter.com
wrote:
> Using node.js, we might have this:
>
> const z = new Z();
> exports.z = z
>
> and then in another file we can
My guess, is that a starting place would be something like:
*var s = time.Now().UTC().String()[0:24]*
an example of which looks like:
"2020-09-23 18:41:43.1568"
so I guess I just to know if there is a reliable way to parse that string
back into a date using multiple programming languages.
Since by default all http requests coming to a go http server are on their
own goroutine, I am wondering if there is a way to have some sort of
"global" variable that is *local* to a goroutine if that makes sense,
something like this, where "gork" is the namespace for variables available
On Wed, Sep 23, 2020 at 10:25 AM Hesham Elhadad wrote:
>
> Thanks Ian,
> The root cause of this issue is not the hard drive, it is something with
> overlapped offset and high offset values, need to be set to 0 to have a
> smooth APPEND to the file.
> I need to use /x/sys/windows package to call
On Wed, Sep 23, 2020 at 5:46 PM Alex Mills wrote:
>
> There appears to be a way to get a reference on the goroutine id:
>
> http://blog.sgmansfield.com/2015/12/goroutine-ids/
But as you can see by reading that blog article, that is almost a joke.
Go considers these things to be better handled
Not a joke, in terms of performance, if you access the goroutine id via the
C library call?
My only concern would be if goroutine id's were reused, if not it would
work.
On Wed, Sep 23, 2020 at 5:54 PM Ian Lance Taylor wrote:
> On Wed, Sep 23, 2020 at 5:46 PM Alex Mills wrote:
> >
> > There
On Wednesday, September 23, 2020 at 1:26:10 PM UTC-4 helhadad wrote:
> Thanks Ian,
> The root cause of this issue is not the hard drive, it is something with
> overlapped offset and high offset values, need to be set to 0 to have a
> smooth APPEND to the file.
> I need to use /x/sys/windows
That looks like something escaped to the heap.
If you pass the -S option to the compiler, the assembly output will have
the symbolic name of the type being allocated (at the LEAQ 2 instructions
before the call to newobject).
If you pass the -m option to the compiler, it will tell you what
On Wed, Sep 23, 2020 at 1:10 AM cs.ali...@gmail.com
wrote:
>
> I am not actually questioning the current design, as you both said it is not
> a good practice to call a return statement as I wrote above, I am trying to
> understand the relation between memory, interface and order of evaluation.
As far as I know, that is exactly what the Context package and customs are
meant for.
[Joop Kiefte - Chat @
Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=p4aw3)
[p4aw3]
On September 24, 2020 at 0:17 GMT, Alex Mills wrote:
Since by default all http requests coming to a
On Wed, Sep 23, 2020 at 6:17 PM Alex Mills wrote:
>
> Since by default all http requests coming to a go http server are on their
> own goroutine, I am wondering if there is a way to have some sort of "global"
> variable that is local to a goroutine if that makes sense, something like
> this,
Not sure about that. Context can store a map. I could map:
request => userid
but then I would have to pass the request to the logging statements, so
that would put me back at square one.
There appears to be a way to get a reference on the goroutine id:
On Wed, 2020-09-23 at 18:12 -0700, Alex Mills wrote:
> But I tried compiling this program:
> https://github.com/davecheney/junk/tree/master/id
>
> and I cant get it to compile/run, the runtime.h file seems MIA
>
> -alex
There is this: https://github.com/kortschak/goroutine
Don't use it; do
But I tried compiling this program:
https://github.com/davecheney/junk/tree/master/id
and I cant get it to compile/run, the runtime.h file seems MIA
-alex
On Wed, Sep 23, 2020 at 6:02 PM Alex Mills wrote:
> Not a joke, in terms of performance, if you access the goroutine id via
> the C
Thanks Axel, Ian!
I am not actually questioning the current design, as you both said it is
not a good practice to call a return statement as I wrote above, I am
trying to understand the relation between memory, interface and order of
evaluation. It is clear that the compiler takes account of
Hey!
Several months ago I opened the proposal for extending the systax of go.mod
in order to allow to specify/overwrite the source URL for a dependency
(https://github.com/golang/go/issues/39536). It feels it could also solve
what you described in "Problem 1", although the motivation behind
On Wed, Sep 23, 2020 at 10:09 AM cs.ali...@gmail.com <
cs.alikoyu...@gmail.com> wrote:
> Is there a paper that I can find why the compiler considers them for
> ordering, why it is important for performance or anything else?
>
>
A CPU has a limit to how many load/store instructions it can issue in
26 matches
Mail list logo
