[go-nuts] On Concurrent-Safety

Is setting a channel to nil, or to another channel, concurrent safe? I guess it is not safe. Because it's a normal variable carrying the channel. But Go does some hidden optimizations, I wondered if this one is of those cases too. -- You received this message because you are subscribed to the

[go-nuts] On Concurrent-Safety

It depends who can see that variable, if this is a global variable, or its address has been taken it is not safe. If the variable is private the goroutine then it is safe becase there is no race on private variables. Remember a variable of type chan is just a pointer. -- You received this mes

[go-nuts] Re: Static race detector?

You might be interested in this: Golang UK Conference 2016 - Nicholas Ng - Static Deadlock Detection for Go: https://www.youtube.com/watch?v=NOQdkbp-950 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop rece

Re: [go-nuts] How Golang implements slice?

Thanks, Edward, you make a good point. What's more, I wrote more code yesterday, and found that we can in fact get the 4th element even if the descriptor tells us there are only 3, by using package unsafe , and doing some simple pointer calculation. It shows that fu

Re: [go-nuts] parsing millisecond coming after colon

Thank you. This is helpful. I am going to replace : with . first. On Tuesday, September 13, 2016 at 9:09:31 AM UTC+5:30, Caleb Spare wrote: > > As Dave said, you should check the error, but unfortunately I think > you'll find that time.Parse doesn't handle fractional seconds that use > a charact

[go-nuts] Re: memory leak with websocket service based on go-socket.io

Finally I fixed the problem. I use the https://github.com/auth0/go-jwt-middleware to auth with JWT. I also open the KeepContext of gorilla mux router to true for that can get the jwt token of request from the goriila context. When I get the jwt token, will clear the request context (via contex

[go-nuts] Re: memory leak with websocket

Finally I fixed the problem. I use the https://github.com/auth0/go-jwt-middleware to auth with JWT. I also open the KeepContext of gorilla mux router to true for that can get the jwt token of request from the goriila context. When I get the jwt token, will clear the request context (via contex

[go-nuts] Re: memory leak with websocket

I'm glad you found the cause of the leak. -- 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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https

Re: [go-nuts] Re: [ANN] A Go based map reduce system (second attempt)

Henrik and David, Yes, this is precisely what pachyderm is trying to accomplish (along with a built in data versioning system). It's pretty wonderful, and I recommend running through their quick start guide: http://pachyderm.readthedocs.io/en/latest/ Daniel On Monday, September 12, 2016 at 1

[go-nuts] Re: [ANN] A Go based map reduce system (second attempt)

Chris, This is great to see! Nice work so far. I enjoyed experimenting with glow and am excited to follow this project. If you are able you might provide some updates in #data-science on gophers slack. I know people there would love to hear about gleam. Best, Daniel On Monday, September 1

[go-nuts] [ANN] google.golang.org/cloud import paths removed

As was announced six weeks ago, the Google Cloud API clients, formerly residing at google.golang.org/cloud/..., have changed import paths to cloud.google.com/go/ The old import paths have now been removed. For details, see https://groups.google.com/forum/#!topic/google-api-go-announce/82-qW

Re: [go-nuts] How Golang implements slice?

Hello Ding Actually you don't need unsafe or reflect to access the 4th element : https://play.golang.org/p/wZAkKtAZei See section "Full slice expressions" in spec about 3-index slicing like a[low : high : max] You were correct in deducing that s

Re: [go-nuts] What is the correct usage for the -msan flag?

On Friday, September 9, 2016 at 1:51:49 PM UTC+2, Ian Lance Taylor wrote: > > I have the following questions concerning the usage of the -msan flag: > > a.) Are these the preferred arguments to use the -msan flag? > > Looks OK to me. > I am wondering if they are really needed, and if yes, why

[go-nuts] Defective information output??? (To Developers)

Hello. https://play.golang.org/p/4IlgcBIbxk Consult me. I believe that the displayed information is incorrect and should be changed in future versions of the language. What I see, it is of little help in debugging. -- You received this message because you are subscribed to the Google Groups "

[go-nuts] Re: Why is there no " declared and not used" compile error?

On Monday, September 12, 2016 at 3:41:35 PM UTC+2, adon...@google.com wrote: > > On Monday, 12 September 2016 08:57:15 UTC-4, Markus Zimmermann wrote: >> >> Hi gophers! >> >> I am wondering why we have a "declared and not used" compile error for >> variables [https://play.golang.org/p/KLzHVO5L7q]

Re: [go-nuts] Defective information output??? (To Developers)

The displayed information is correct as specified. Use a different format if you want different output. In this example, %q is a good choice. https://play.golang.org/p/Wyxv8md1qu -rob On Tue, Sep 13, 2016 at 4:35 PM, Александр Петров wrote: > Hello. > > https://play.golang.org/p/4IlgcBIbxk >

Re: [go-nuts] Defective information output??? (To Developers)

On Tue, Sep 13, 2016 at 2:19 PM Александр Петров wrote: > Consult me. I believe that the displayed information is incorrect and should be changed in future versions of the language. > What I see, it is of little help in debugging. https://play.golang.org/p/jQJJoknb3v -- -j -- You received

[go-nuts] Re: Why is there no " declared and not used" compile error?

On Monday, September 12, 2016 at 3:21:50 PM UTC+2, Sjon Kosse wrote: > > Hello, > > Const values can be accesed still by reflection in a reasonable manner. > This question has come by quite a few times before on the mailing list, > better explanations should be easy to find. > I do not think tha

Re: [go-nuts] Defective information output??? (To Developers)

Yes. It's a false alarm. Topic can be closed. Peoples prompted me that the format %#v - that just does what I need, a quoted string. Sorry for disturb вторник, 13 сентября 2016 г., 15:27:38 UTC+3 пользователь Jan Mercl написал: > > On Tue, Sep 13, 2016 at 2:19 PM Александр Петров > wrote: > >

Re: [go-nuts] Defective information output??? (To Developers)

On Tue, Sep 13, 2016 at 2:58 PM Александр Петров wrote: > Yes. It's a false alarm. Topic can be closed. Peoples prompted me that the format %#v - that just does what I need, a quoted string. %#v actually does probably what you need ( https://play.golang.org/p/8th0Znz-9p), but the program in the

Re: [go-nuts] Re: Another divide by zero (float) question

float32(0) is a constant, a typed constant. The following statement is valid: const z = float32(0) So it is following the part of the spec that Ian pointed out. -Paul On Mon, Sep 12, 2016 at 5:15 PM, wrote: > I see - so if I understood correctly the spec for constants disallowing > divid

[go-nuts] Re: Why is there no " declared and not used" compile error?

On 13 September 2016 at 08:22, Markus Zimmermann wrote: > On Monday, September 12, 2016 at 3:41:35 PM UTC+2, adon...@google.com > wrote: >> >> unused constants and types cost nothing at run time. It's not that >> simple, of course, because constant and type declarations may be the only >> uses o

Re: [go-nuts] [ANN] google.golang.org/cloud import paths removed

The links on the docs for this are currently broken e.g. https://cloud.google.com/go/apis points to https://godoc.org/google.golang.org/cloud On 13/09/2016 12:59, jba via golang-nuts wrote: As was announced six weeks ago, the Google Cloud API clients, formerly residing at google.golang.org/clo

Re: [go-nuts] Multiple-reader single-writer map access - is this lockless workaround safe?

I think it is pretty common to make your map/list "read only" and to update it by a replace. That does not get you away from the need for a mutex, however. There is still a reader and writer: Reader: v := m[key] Writer: m = newMap Those two operations are not safe together. You still nee

Re: [go-nuts] Multiple-reader single-writer map access - is this lockless workaround safe?

On 13 September 2016 at 10:33, 'Paul Borman' via golang-nuts < golang-nuts@googlegroups.com> wrote: > That said, a map is represented by a single machine word (32 or 64 bits). > I don't know of any modern architecture where reading a cache aligned word > while it is being written will yield anythi

[go-nuts] Max age for TCP connection

Hi, We've got a HTTP client connecting to an active-passive cluster setup, controlled through a traffic managed DNS entry and a good-to-go signal on each cluster. When the good-to-go fails, the DNS switches to point at the passive cluster. The client in question has no knowledge of whether a

Re: [go-nuts] Multiple-reader single-writer map access - is this lockless workaround safe?

Yes, that is very true, though in the OP's case, the memory barrier can easily be done by the writer without affecting the reader (simply by switching the write to the channel with the assignment of x.myMap). Granted, the reader might have stale information, but I believe that the compiler currentl

Re: [go-nuts] Cross-compilation of golang assembly via 'go tool asm'

On Tue, Sep 13, 2016 at 6:19 AM, wrote: > My interpretation of golang's assembly is that it represents an intermediate > pseudo-language that is transformed via "instruction selection" to a > concrete form. Correct, but this pseudo-language is not portable between architectures. > Therefore, is

Re: [go-nuts] What is the correct usage for the -msan flag?

On Tue, Sep 13, 2016 at 5:03 AM, Markus Zimmermann wrote: > On Friday, September 9, 2016 at 1:51:49 PM UTC+2, Ian Lance Taylor wrote: >> >> > I have the following questions concerning the usage of the -msan flag: >> > a.) Are these the preferred arguments to use the -msan flag? >> >> Looks OK to m

[go-nuts] Re: Static race detector?

Thanks for all links and answers! -- 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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups

[go-nuts] Re: Max age for TCP connection

What is your http.Client.Timeout value? On Tuesday, September 13, 2016 at 8:57:45 AM UTC-6, david...@ft.com wrote: > > Hi, > > We've got a HTTP client connecting to an active-passive cluster setup, > controlled through a traffic managed DNS entry and a good-to-go signal on > each cluster. When

Re: [go-nuts] Cross-compilation of golang assembly via 'go tool asm'

Thanks Aram and Michael, that helps a lot. I've studied https://github.com/golang/go/tree/master/src/crypto/sha1 which looks like a good example of having a pure-go fallback with architecture-specific assembly. My next question is which tool is responsible for selecting the correct sha1blo

Re: [go-nuts] Multiple-reader single-writer map access - is this lockless workaround safe?

On Tuesday, September 13, 2016 at 9:48:06 AM UTC+8, Caleb Spare wrote: > > See > https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong. > > > I've read this article before and the second reading hasn't done much to improve my impression. The premise i

Re: [go-nuts] Multiple-reader single-writer map access - is this lockless workaround safe?

On 13 September 2016 at 12:36, sqweek E. wrote: > On Tuesday, September 13, 2016 at 9:48:06 AM UTC+8, Caleb Spare wrote: >> >> See https://software.intel.com/en-us/blogs/2013/01/06/benign-dat >> a-races-what-could-possibly-go-wrong. >> > > I've read this article before and the second reading hasn

Re: [go-nuts] Cross-compilation of golang assembly via 'go tool asm'

On Tuesday, September 13, 2016 at 11:08:18 AM UTC-5, pcj...@gmail.com wrote: > > My next question is which tool is responsible for selecting the correct > sha1block_GOARCH.s? Is the the compiler, linker, or where? > See https://golang.org/pkg/go/build/ (under Build Constraints) And (as of Go 1

Re: [go-nuts] Multiple-reader single-writer map access - is this lockless workaround safe?

On Tuesday, September 13, 2016 at 10:57:47 PM UTC+8, Alan Donovan wrote: > > On 13 September 2016 at 10:33, 'Paul Borman' via golang-nuts < > golan...@googlegroups.com > wrote: > >> That said, a map is represented by a single machine word (32 or 64 >> bits). I don't know of any modern architectur

Re: [go-nuts] How Golang implements slice?

Doh. I keep forgetting about a[low : high : max], but also want to point out that if that if the slice is modified by the func beyond cap then the backing array will be swapped out anyway and your slice header doesn't know about the swap or the new cap. On Tue, Sep 13, 2016 at 5:00 AM Val wrote:

[go-nuts] Type Scope?

I think I'm having some type of mental lapse, but can anyone tell me why this doesn't print out "It works!" nor give me an error? It simply prints an empty string... https://play.golang.org/p/9oG0S8kfM3 package main import "fmt" type fetcher struct { names string } func (f fetcher) Set(tname

Re: [go-nuts] Type Scope?

On Tue, Sep 13, 2016 at 1:41 PM, Frank Davidson wrote: > func (f fetcher) Set(tname string) fetcher is not a pointer, therefore when you do "me.Set" f is a cpoy and tname is only set on the copy (and then promptly discarded). The example should be: > func (f *fetcher) Set(tname… —Sam -- Sam

[go-nuts] Re: Type Scope?

You need a pointer receiver on Set. It copies the struct, sets the field on the copy, and throws it away: https://play.golang.org/p/mqleaL6PU3 On Tuesday, September 13, 2016 at 11:41:46 AM UTC-7, Frank Davidson wrote: > > I think I'm having some type of mental lapse, but can anyone tell me why

[go-nuts] Having difficulty testing this "cleanly"

Has anyone come across a good way, non-racy way to ensure that N tasks are guaranteed to be completed after a function is called? Essentially I have a “Close” function that must be guaranteed to block until all tasks are finished. Achieving this was pretty simple: wrap each task in an RLock, and

Re: [go-nuts] Multiple-reader single-writer map access - is this lockless workaround safe?

I think this will be an interesting read especially if you come from Java. https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/ On Tue, Sep 13, 2016, 19:08 sqweek E. wrote: > On Tuesday, September 13, 2016 at 10:57:47 PM UTC+8, Alan Donovan wrote: > >> On 13 September 2016 at 10:33, 'Pa

RE: [go-nuts] Having difficulty testing this "cleanly"

Have you considered using a sync.WaitGroup? John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Evan Digby Sent: 2016 September 13, Tue 13:56 To: golang-nuts Subject: [go-nuts] Having difficulty testing this "clean

Re: [go-nuts] Multiple-reader single-writer map access - is this lockless workaround safe?

On Tue, Sep 13, 2016 at 9:36 AM, sqweek E. wrote: > > The remaining examples sound indistinguishable from compiler bugs. Developers of C/C++ compilers rigorously rely on the language standard's definition of undefined behavior when optimizing programs. This can lead to many behaviors that, when f

[go-nuts] Re: Type Scope?

Thanks, guys! So, just for me to be clear, the line me.Set("It works!") in my original code created a copy of the "me" fetcher, set its names field, and then threw it away, leaving the original "me.name" with an unaltered, empty string value? On Tuesday, September 13, 2016 at 2:41:46 PM UTC-4

[go-nuts] Re: Type Scope?

That's correct. Method receivers are equivalent to just passing as an extra argument: func Set(f fetcher, tname string) { f.names = tname } In this case, it's obvious that Set will not affect the fetcher passed in at the call site, in contrast to func Set(f *fetcher, tname string) { f.names =

Re: [go-nuts] Having difficulty testing this "cleanly"

Hi John, Thanks for the reply. I've tried many incarnations that include WaitGroups; however, none seem to achieve the desired result. If I add a WaitGroup with a defer done in the handler, and then wait after the Close() then the test itself implements the requirement and won't protect from

Re: [go-nuts] Having difficulty testing this "cleanly"

The WaitGroup is better than the lock approach, since the lock approach could block an outstanding task. The key to using waitgroups is to call Add() outside of goroutines that might call done: https://play.golang.org/p/QVWoy8fCmI On Tuesday, September 13, 2016 at 12:19:16 PM UTC-7, Evan Digby

[go-nuts] Re: Having difficulty testing this "cleanly"

counter := intr64(N) release := make(chan struct{}) ... for i := 0; i < N; i ++ { h.Handle(func() { <-release atomic.AddInt64(&counter, -1) }) } ... go func(){ time.Sleep(time.Millisecond) // so we would certainly hit h.Close, before we continue for i := 0; i < N; i++ { r

RE: [go-nuts] Having difficulty testing this "cleanly"

Hi Evan. I looked at the code you posted. I’m having a problem seeing exactly what you are trying to do. Also, it appears to be using multiple synchronization techniques: Mutex, WaitGroup, and 2 blocking channels. Am I correct in guessing that you want to know how long it took to get al

Re: [go-nuts] Having difficulty testing this "cleanly"

Hi Aroman, Your approach using the WaitGroup is definitely better in this toy example. The reason I didn't use the WaitGroup is because the non-toy example is wrapping the HTTP Server handler. I have no way to inject an "add" before the goroutine is created since that's handled by Go's HTTP Ser

[go-nuts] Re: Having difficulty testing this "cleanly"

Hi Egon, This is essentially the strategy I'm taking; however, I am hoping to avoid the "Sleep and Pray" method. Reliable in practice, but not guaranteed. Also in a CI of thousands of tests, adding time arbitrarily can extend out the time it takes to test quite a bit. That said, if a sleep is

RE: [go-nuts] Having difficulty testing this "cleanly"

Hi again. Ø There's no way to test that a WaitGroup is done without waiting for it, and even if there was it would be racy because between the Close() and WaitGroup wait call tasks could complete. If you don’t mind being blocked, then Wait is just what you want. Since it’s occurring in

Re: [go-nuts] Having difficulty testing this "cleanly"

I do mind being blocked, because if the test blocks (consider what's in "main" a test) then it is going to enforce the requirement that I want to see in the implementation. It won't protect me, and will make the test obsolete. What I'm trying to test is that all handlers are complete after the

Re: [go-nuts] Having difficulty testing this "cleanly"

Hi John, Consider the "main" function a test, and not a sane usage of the handler. The multiple sync methods in "main" are trying to accomplish: 1) Ensure all tasks have started (allStarted waitgroup) 2) Wait until we're ready to call "Done" before we proceed with the task (timeToFinish channel

RE: [go-nuts] Having difficulty testing this "cleanly"

Ø The RW mutex is used by the implementation to guarantee that all handlers are complete before we return from "Close", which is what I'm attempting to test. I’m not sure that the mutex is going to work like you want. There’s no guarantee that the h.RLock() in the goroutine will execute in

[go-nuts] Re: Having difficulty testing this "cleanly"

On Tuesday, 13 September 2016 22:52:27 UTC+3, Evan Digby wrote: > > Hi Egon, > > This is essentially the strategy I'm taking; however, I am hoping to avoid > the "Sleep and Pray" method. Reliable in practice, but not guaranteed. Also > in a CI of thousands of tests, adding time arbitrarily can ex

Re: [go-nuts] Having difficulty testing this "cleanly"

Hi John, You're absolutely right, there is definitely a race condition that we've accepted here. We're trading that off vs. reimplementing large parts of the existing http server so that we can inject the rlock (or wg.Add(1)) before golang spawns the goroutine for the request. This race condit

[go-nuts] Re: Having difficulty testing this "cleanly"

Hi Egon, I appreciate the effort you've (and everyone has) put in thus-far! Correct me if I'm wrong, but I think you're pointing out the race condition John pointed. That's a tradeoff we've accepted so we don't need to reimplement much of http.Serve so that we can add a waitgroup Add or Rlock

Re: [go-nuts] Having difficulty testing this "cleanly"

The mutex approach is fundamentally broken because you can't guarantee that the tasks are all started (and have a read-lock acquired) before you call close. Consider: h.Handle(...) <-- gets past the closed channel check, calls go ..., butthe goroutine doesn't execute yet. h.Close() <-- closes

Re: [go-nuts] Having difficulty testing this "cleanly"

Hi John/Egon/Augusto, I should point out is that all we need to guarantee (barring abnormal termination of course) is that once a task starts processing, it finishes. Partially processed messages are bad, but http requests that don't result in a message being processed at all are okay. We don'

Re: [go-nuts] Having difficulty testing this "cleanly"

Hi Augusto, We have considered using 3rd party graceful shutdown libraries; however, they mostly (all?) seem to re-implement the Server type. This means that if Go were to release a security fix, or other urgent fix to this logic, we wouldn't get it right away. We now depend on a 3rd party to k

Re: [go-nuts] Having difficulty testing this "cleanly"

Hi Augusto, I do owe you an apology. Our production code has the check on the closed channel after the RLock, not before. In this case you are 100% correct. This was a bad transcription of the production code to the toy example. Thanks again, Evan On Tuesday, 13 September 2016 13:24:03 UTC-7,

RE: [go-nuts] Having difficulty testing this "cleanly"

Hi Evan. I still don’t quite understand exactly what you are shooting for. I tried to reimplement what you posted originally. Check out https://play.golang.org/p/koUJYCKFpa. Does this come close functionally? John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.

Re: [go-nuts] Having difficulty testing this "cleanly"

Hi John, What you've posted is a valid way to implement the handler, but not a way to validate it. The implementation in the example isn't the problem. It's how to validate the implementation with a test. If we add a WaitGroup.Wait inside the handler then the test is not valid because it will wa

RE: [go-nuts] Having difficulty testing this "cleanly"

OK. Give me a minute to add that. I just wanted to make sure I was headed in the right direction. J Note: In looking at your original code I didn’t see any way that the error could happen, so I ignored that case. Given this, there was no need for the h.closed channel. Back in a few.

Re: [go-nuts] Having difficulty testing this "cleanly"

Hi John, Thank you! The h.closed channel, if checked properly (after the RLock), prevents the race condition that Augusto pointed out in his post a few back. I fixed my implementation here: https://play.golang.org/p/QTkSJAOPtE Thanks again, Evan On Tue, 13 Sep 2016 at 14:04 John Souvestre wr

Re: [go-nuts] Having difficulty testing this "cleanly"

On Tuesday, 13 September 2016 23:31:55 UTC+3, Evan Digby wrote: > > Hi John/Egon/Augusto, > > I should point out is that all we need to guarantee (barring abnormal > termination of course) is that once a task starts processing, it finishes. > Partially processed messages are bad, but http request

Re: [go-nuts] Having difficulty testing this "cleanly"

Hi Egon, My requirements are more simple than a graceful http shutdown. I simply require that everything that enters the RLock completes to RUnlock. Accepted requests, or even calls to servehttp can die without issue as long as they haven't entered the processing in the RLock. If the server crash

RE: [go-nuts] Having difficulty testing this "cleanly"

OK. Check this one out. https://play.golang.org/p/kO_96oykG1 John John Souvestre - New Orleans LA From: Evan Digby [mailto:evandi...@gmail.com] Sent: 2016 September 13, Tue 16:06 To: John Souvestre; golang-nuts@googlegroups.com Subject: Re: [go-nuts] Having difficulty testing this "

Re: [go-nuts] Having difficulty testing this "cleanly"

On Wednesday, 14 September 2016 00:18:26 UTC+3, Evan Digby wrote: > > Hi Egon, > > My requirements are more simple than a graceful http shutdown. I simply > require that everything that enters the RLock completes to RUnlock. > Accepted requests, or even calls to servehttp can die without issue

Re: [go-nuts] Re: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

On Tue, Sep 13, 2016 at 3:31 PM wrote: > I've spent many, many, many hours on this (measured in days, at this > point) and I'm convinced that Golang is missing a fundamental programming > capability, that of multidimensional associative arrays. Searching through > this forum's archives and other

RE: [go-nuts] Having difficulty testing this "cleanly"

Or, if you have something else you’d rather be doing while waiting… https://play.golang.org/p/rhwEpWMhqF John John Souvestre - New Orleans LA From: John Souvestre [mailto:j...@souvestre.com] Sent: 2016 September 13, Tue 16:21 To: 'golang-nuts@googlegroups.com' Subject: RE: [go-nuts]

Re: [go-nuts] Having difficulty testing this "cleanly"

Hi Egon, Thanks for that. It seems to implement the same requirements as implemented in my example, although I prefer my implementation as it doesn't require a sleep/loop. The implementation I provided in the original email, with the exception of the bug that Augusto pointed out, works as desired

Re: [go-nuts] Cross-compilation of golang assembly via 'go tool asm'

Thanks, great reference to gooOsArchFile() On Tuesday, September 13, 2016 at 11:04:44 AM UTC-6, ironi...@gmail.com wrote: > > > > On Tuesday, September 13, 2016 at 11:08:18 AM UTC-5, pcj...@gmail.com > wrote: >> >> My next question is which tool is responsible for selecting the correct >> sha1b

Re: [go-nuts] Having difficulty testing this "cleanly"

The way to test it is something like this: https://play.golang.org/p/8hN9q9ibIc Specifically, have the handler push to start & finish channels. In the monitoring goroutine, you can record events for start, finish, & close (and anything else you want to check, maybe Queue?). After the call to

Re: [go-nuts] Having difficulty testing this "cleanly"

By the way, the latest code at https://play.golang.org/p/QTkSJAOPtE isn't great, because once Close() is called, new tasks will be blocked until existing tasks finish. That is, once Lock() is called in Close(), subsequent RLocks() are blocked. At least, this is document in an old version of th

[go-nuts] handling duplicate keys in yaml

Hi all, I am using go-yaml to parse yaml files. I noticed that if there are duplicate keys in a yaml map, then the parser silently replaces the previous value with the new one. Is there any way to treat this as a parser exception with this library or would I need to create a custom parser for

[go-nuts] Re: Max age for TCP connection

Hi David, I saw similar solutions using DNS to add / remove node from cluster, the client side spin up a go routine keep resolving the DNS in an interval, if it find new ip appears in DNS record, add it to the pool , when ip address disappear from the DNS, it removes from the pool.

Re: [go-nuts] Having difficulty testing this "cleanly"

On Wednesday, 14 September 2016 00:58:39 UTC+3, Evan Digby wrote: > > Hi Egon, > > Thanks for that. It seems to implement the same requirements as > implemented in my example, although I prefer my implementation as it > doesn't require a sleep/loop. > I used sleep/loop because I probably was th

Re: [go-nuts] Having difficulty testing this "cleanly"

Hi All, Firstly, I really appreciate the care and attention everyone is putting into this. I'm finding this challenge fun to navigate. Secondly, I don't feel so silly anymore because clearly this is a non-trivial task. I'm going to have to take a bit to let the last couple of suggestions sink