[go-nuts] Wmi-exporter add new collector

How do I create a new collector to get a metric from a class say, root/microsoft -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to

[go-nuts] cgo:build trouble

package main import( ) /* #include */ import "C" func main() { C.printf(C.CString("hello")) } //>build this file with go build, i got //./testems.go:12:2: unexpected type: ... could someone help me with this trouble? thanks! -- You received this message because you are subscribed to

Re: [go-nuts] Re: Go 1.12.1 and Go 1.11.6 are released

On Sun, Mar 17, 2019 at 1:46 PM Serhat Şevki Dinçer wrote: > > I see a regression on speed with sorty tests (go test -short -gcflags '-B -s' > -ldflags '-s -w') on my Intel Core i5-4210M laptop (also sortutil became > faster, zermelo float became much slower): Please open an issue with full

[go-nuts] panic at fmt.Printlb

Hi, I got a panic when i run my test code my go version is 'go version go1.12 linux/amd64' panic: reflect: call of reflect.Value.Type on zero Value goroutine 6 [running]: reflect.Value.Type(0x0, 0x0, 0x0, 0x4db0c0, 0xc183d0) /usr/local/go/src/reflect/value.go:1813 +0x169

Re: [go-nuts] Is this a valid way of implementing a mutex?

Op zo 17 mrt. 2019 om 15:28 schreef Louki Sumirniy : > As my simple iterative example showed, given the same sequence of events, > channels are deterministic, so this is an approach that is orthogonal but in > the same purpose - to prevent multiple concurrent agents from desynchronising >

Re: [go-nuts] Is this a valid way of implementing a mutex?

This was a good link to follow: https://en.wikipedia.org/wiki/Bulk_synchronous_parallel led me here: https://en.wikipedia.org/wiki/Automatic_mutual_exclusion and then to here: https://en.wikipedia.org/wiki/Transactional_memory I think this is the pattern for implementing this using channels

Re: [go-nuts] Is this a valid way of implementing a mutex?

Ah yes, probably 'loop1' 'loop2' would be more accurate names. Yes the number of each routine is in that 'i' variable, those other labels are just to denote the position within the loops and before and after sending and the state of the truthstate variable that is only accessed inside the

Re: [go-nuts] Is this a valid way of implementing a mutex?

I like to think of a channel as a concurrent messaging queue. You can do all sorts of things with such constructs, including implementing mutual exclusion constructs, but that doesn't mean that one is the other. Your playground example is a bit weird and very prone to various kinds of race

Re: [go-nuts] Is this a valid way of implementing a mutex?

Then use a mutex or atomic spin lock (although that may have issues in the current Go implementation) > On Mar 17, 2019, at 3:56 PM, Louki Sumirniy > wrote: > > I am pretty sure the main cause of deadlocks not having senders and receivers > in pairs in the execution path such that senders

Re: [go-nuts] Is this a valid way of implementing a mutex?

I am pretty sure the main cause of deadlocks not having senders and receivers in pairs in the execution path such that senders precede receivers. Receivers wait to get something, and in another post here I showed a playground that demonstrates that if there is one channel only one thread is

Re: [go-nuts] Is this a valid way of implementing a mutex?

Without reading too deeply, and only judging based on your statements, it seems you are confusing implementation with specification. The things you cite are subject to change. You need to reason based on the specification not the observed behavior. Then use the observed behavior to argue that

Re: [go-nuts] Is this a valid way of implementing a mutex?

https://play.golang.org/p/Kz9SsFeb1iK This prints something at each interstice of the execution path and it is of course deterministic. I think the reason why the range loop always chooses one per channel, last one in order because it uses a LIFO queue so the last in line gets filled first.

[go-nuts] Re: Go 1.12.1 and Go 1.11.6 are released

Hi, I see a regression on speed with sorty tests (go test -short -gcflags '-B -s' -ldflags '-s -w') on my Intel Core i5-4210M laptop (also sortutil became faster, zermelo float became much slower): with *go 1.12.1* Sorting uint32 sortutil took 18.64s zermelo

Re: [go-nuts] Is this a valid way of implementing a mutex?

https://play.golang.org/p/13GNgAyEcYv I think this demonstrates how it works quite well, it appears that threads stick to channels, routine 0 always sends first and 1 always receives, and this makes sense as this is the order of their invocation. I could make more parallel threads but clearly

Re: [go-nuts] Is this a valid way of implementing a mutex?

https://g.co/kgs/2Q3a5n > On Mar 17, 2019, at 2:36 PM, Louki Sumirniy > wrote: > > So I am incorrect that only one goroutine can access a channel at once? I > don't understand, only one select or receive or send can happen at one moment > per channel, so that means that if one has started

Re: [go-nuts] Is this a valid way of implementing a mutex?

On Sun, Mar 17, 2019 at 8:36 PM Louki Sumirniy < louki.sumirniy.stal...@gmail.com> wrote: > So I am incorrect that only one goroutine can access a channel at once? I don't understand, only one select or receive or send can happen at one moment per channel, so that means that if one has started

Re: [go-nuts] Is this a valid way of implementing a mutex?

So I am incorrect that only one goroutine can access a channel at once? I don't understand, only one select or receive or send can happen at one moment per channel, so that means that if one has started others can't start. I was sure this was the case and this seems to confirm it:

Re: [go-nuts] Is this a valid way of implementing a mutex?

On Sun, Mar 17, 2019 at 1:04 PM Louki Sumirniy < louki.sumirniy.stal...@gmail.com> wrote: > My understanding of channels is they basically create exclusion by control of the path of execution, instead of using callbacks, or they bottleneck via the cpu thread which is the reader and writer of this

[go-nuts] Re: Elastic synchronised logging : What do you think ?

I didn't even think of the idea of using buffered channels, I was trying to not lean too far in towards that side of thing, but it is good you mention it, it would be simple to just pre-allocate a buffer and trigger the print call only when that buffer fills up (say like half a screenful, maybe

[go-nuts] Re: Elastic synchronised logging : What do you think ?

I just wrote this a bit over a month ago: https://git.parallelcoin.io/dev/pod/src/branch/master/pkg/util/cl It was brutal simple before (only one 600 line source lots of type switches) but it now also has a registration system for setting up arbitrary subsystem log levels. By the way, I could

Re: [go-nuts] Is this a valid way of implementing a mutex?

I didn't mention actually excluding access by passing data through values either, this was just using a flag to confine accessor code to one thread, essentially, which has the same result as a mutex as far as its granularity goes. On Sunday, 17 March 2019 13:04:26 UTC+1, Louki Sumirniy wrote:

Re: [go-nuts] Is this a valid way of implementing a mutex?

My understanding of channels is they basically create exclusion by control of the path of execution, instead of using callbacks, or they bottleneck via the cpu thread which is the reader and writer of this shared data anyway. I think the way they work is that there is queues for read and write

[go-nuts] Re: Elastic synchronised logging : What do you think ?

Please replace 'case ticker.C' with 'case <-ticker.C' in my previous code. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [go-nuts] Re: Persistence of value, or Safely close what you expected

I am currently dealing with a race related bug, at least, I found a bug, and it coincided with a race when I enabled the race detector, and the bug is a deadlock, and the shared shut-down button clearly can be pressed on and off in the wrong order. So my first strategy in fixing the bug is

[go-nuts] Is this a valid way of implementing a mutex?

I just ran into my first race condition-related error and it made me wonder about how one takes advantage of the mutex properties of channels. If I understand correctly, this is a simple example: mx := make(chan bool) // in separate scope, presumably... go func() { <-mx

[go-nuts] Elastic synchronised logging : What do you think ?

What you did is decouple production from consumption. You can speed up the production go routine if the rate is irregular. But if, on average, consumption is too slow, the list will grow until out of memory. If you want to speed up consumption, you may group the strings in one big string and

[go-nuts] Elastic synchronised logging : What do you think ?

Buffer your output using bufio.NewWriterSize. Using a buffered channel gives nothing: is the producers are faster, then the buffers will always be full, the bottleneck is the ouput writer. If the consumer is faster, then you have no problems :) Buffering the output speeds things up as the main

Re: [go-nuts] Order of evaluation need more definition in spec

Upon reflection I see that this is as you say. Not only expressed hazards, but even such mysterious cases as file system modification yb external scripts invoked by one argument and visible to another. On Sat, Mar 16, 2019 at 10:03 PM T L wrote: > > > On Friday, March 15, 2019 at 2:25:44 PM