Not true. The race detector does not detect certain cases and can overreport. One the memory model becomes fully specified it may not be the case but if would be very hard to implement something that didn’t work as I’ve said
Still you can just as easily change the other two accesses to be atomic but it’s not needed. > On Sep 1, 2019, at 12:55 PM, T L <tapir....@gmail.com> wrote: > > You can simply validate it by run: go run -race main.go > for you program: https://play.golang.org/p/JRSEPU3Uf17 > > >> On Sunday, September 1, 2019 at 1:30:30 PM UTC-4, Robert Engels wrote: >> The memory model is pretty unspecified but they’re working on it. As a >> defacto behavior it is pretty hard to have what I stated not be the case. >> >>> On Sep 1, 2019, at 9:46 AM, T L <tapi...@gmail.com> wrote: >>> >>> This is not true, at least no Go official documentation admits this. >>> >>>> On Sunday, September 1, 2019 at 7:42:38 AM UTC-4, Robert Engels wrote: >>>> That is incorrect. The atomic operations must exhibit the same happens >>>> before relationships as the mutex. If the mutex flushes the related cache >>>> lines the atomic load will pick it up. >>>> >>>>> On Aug 31, 2019, at 10:55 PM, T L <tapi...@gmail.com> wrote: >>>>> >>>>> >>>>> >>>>>> On Saturday, August 31, 2019 at 9:49:56 PM UTC-4, Robert Engels wrote: >>>>>> Yes, that is why the original code did not use a lock on the read but >>>>>> the read of the flag was wrong. The version I posted in the other thread >>>>>> works fine locally. time.Sleep() has problems in the playground >>>>> >>>>> You mean this one: https://play.golang.org/p/JRSEPU3Uf17 ? >>>>> No no, it is not a good ideas to use mutex in write but atomic in read to >>>>> avoid concurrently accessing the same value. >>>>> >>>>>> >>>>>>> On Aug 31, 2019, at 7:50 AM, T L <tapi...@gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote: >>>>>>>> If you comment out the read method then all threads will block. That >>>>>>>> is the the behavior of an unbuffered channel - a writer blocks until a >>>>>>>> reader is ready. Which is why you always need a valid reader running. >>>>>>>> Unless the channel is closed and then the writer will panic. >>>>>>>> >>>>>>>> The code I provided is valid. >>>>>>> >>>>>>> In fact, if I comment out the write instead read part, the code will >>>>>>> also crash on all goroutines are blocked. >>>>>>> >>>>>>>> >>>>>>>>> On Aug 31, 2019, at 2:40 AM, T L <tapi...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote: >>>>>>>>>> You changed the Read() method incorrectly - it should be using the >>>>>>>>>> Read lock, not the Write lock. >>>>>>>>>> >>>>>>>>>> Still, as I pointed out when I posted it, Play has a problem where >>>>>>>>>> it aborts if all routines are sleeping (not just blocked), so you >>>>>>>>>> need to run it locally. >>>>>>>>> >>>>>>>>> My fault. But it doesn't matter, for the Read method is never called >>>>>>>>> (I commented it off). >>>>>>>>> It also crash locally for all goroutines are blocked. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: T L >>>>>>>>>> Sent: Aug 30, 2019 12:05 PM >>>>>>>>>> To: golang-nuts >>>>>>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Makes no difference in the code I posted.... as long as they all >>>>>>>>>>> use the same MultiWriterChannel. In fact, others can be late >>>>>>>>>>> started, as they will fail fast if the channel is already closed. >>>>>>>>>> >>>>>>>>>> https://play.golang.org/p/pcwIu2w8ZRb >>>>>>>>>> >>>>>>>>>> All go routines are blocked in the modified version. >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: T L >>>>>>>>>>> Sent: Aug 30, 2019 11:13 AM >>>>>>>>>>> To: golang-nuts >>>>>>>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select >>>>>>>>>>> cases >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels >>>>>>>>>>>> wrote: >>>>>>>>>>>> I don't think so. Why do you think that is the case? The RWLock is >>>>>>>>>>>> "fair" in the sense that once the 'closer' attempts to get the >>>>>>>>>>>> lock, it is guaranteed to get it (as the code is structured) - the >>>>>>>>>>>> subsequent readers will queue behind the "writer = closer". >>>>>>>>>>> >>>>>>>>>>> How about unknown/random number of senders and readers? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: T L >>>>>>>>>>>> Sent: Aug 30, 2019 8:50 AM >>>>>>>>>>>> To: golang-nuts >>>>>>>>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select >>>>>>>>>>>> cases >>>>>>>>>>>> >>>>>>>>>>>> @Robert >>>>>>>>>>>> I think there is a difference between the code of @Leo and you. >>>>>>>>>>>> In you code, the Wirte/Read/Close are all possible to block for >>>>>>>>>>>> ever. >>>>>>>>>>>> >>>>>>>>>>>>> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Oops. You are right. The original used two different methods >>>>>>>>>>>>> Closed() and Read() and when I refactored I forgot to add the >>>>>>>>>>>>> Read lock to the Read(). That's why you always have code >>>>>>>>>>>>> reviews... >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: T L >>>>>>>>>>>>> Sent: Aug 29, 2019 6:25 PM >>>>>>>>>>>>> To: golang-nuts >>>>>>>>>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select >>>>>>>>>>>>> cases >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert >>>>>>>>>>>>>> engels wrote: >>>>>>>>>>>>>> Here is a version using RWLock >>>>>>>>>>>>>> https://play.golang.org/p/YOwuYFiqtlf >>>>>>>>>>>>> >>>>>>>>>>>>> Doesn't the Read method need to be guarded by the reader lock? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> It won’t run correctly in the playground because it terminates >>>>>>>>>>>>>> when all routines are asleep - which happens during the test >>>>>>>>>>>>>> (not sure why it does this, as sleeping is different than a >>>>>>>>>>>>>> deadlock). >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is probably less efficient, and less orderly than the other >>>>>>>>>>>>>> example using WaitGroup but you get the idea I hope. It forcibly >>>>>>>>>>>>>> terminates the writers before they complete by design. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Aug 28, 2019, at 4:09 PM, Michel Levieux >>>>>>>>>>>>>>> <m.le...@capitaldata.fr> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> One should also be careful regarding the conceptual demands he >>>>>>>>>>>>>>> or she is making. >>>>>>>>>>>>>>> Having a shared resource (that is complex enough that it cannot >>>>>>>>>>>>>>> be atomically accessed or modified) means essentially that >>>>>>>>>>>>>>> "having multiple writers being transparent to the readers", >>>>>>>>>>>>>>> fundamentally, is not possible. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From the moment itself when such a resource is shared, there >>>>>>>>>>>>>>> must be some sort of mecanism (that one using resources >>>>>>>>>>>>>>> atomically usable) that ensures the integrity of it. >>>>>>>>>>>>>>> Maybe what you're talking about is having it transparent in >>>>>>>>>>>>>>> terms of code, in which case we both agree, but if you're >>>>>>>>>>>>>>> looking for something transparent in essence, as in >>>>>>>>>>>>>>> performance, logical construction and all the rest, I think >>>>>>>>>>>>>>> there is a misunderstanding here: even if it was added in the >>>>>>>>>>>>>>> language, there would be many many things going on under the >>>>>>>>>>>>>>> hood, as it is already (and cannot really be otherwise) for >>>>>>>>>>>>>>> channel use alone. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As for the priority using selects, I think it's more of >>>>>>>>>>>>>>> something to be dealt with on the "user-side". There are many >>>>>>>>>>>>>>> kinds of priority in general, and trying to implement something >>>>>>>>>>>>>>> in the language itself would IMO either be too specific >>>>>>>>>>>>>>> compared to the nessecary time to do so or it would probably >>>>>>>>>>>>>>> have a huge overhead on the "classical' use case of the select >>>>>>>>>>>>>>> construct. >>>>>>>>>>>>>>> + the fact that it is apparently already possible using >>>>>>>>>>>>>>> RWMutexes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz >>>>>>>>>>>>>>>> <mar...@gmail.com> a écrit : >>>>>>>>>>>>>>>> Think of a channel as existing for the lifetime of a >>>>>>>>>>>>>>>> particular data stream, and not have it be associated with >>>>>>>>>>>>>>>> either producer or consumer. Here's an example: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://play.golang.org/p/aEAXXtz2X1g >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The channel here is closed after all producers have exited, >>>>>>>>>>>>>>>> and all consumers continue to run until the channel is drained >>>>>>>>>>>>>>>> of data. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The producers are managed by something somewhere in your code >>>>>>>>>>>>>>>> - and that is the scope at which it makes sense to create >>>>>>>>>>>>>>>> channel ownership. I've used a waitgroup to ensure that the >>>>>>>>>>>>>>>> channel is closed after all producers exit, but you can use >>>>>>>>>>>>>>>> whatever barrier construct you want. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Even if you must have a channel per producer, you can safely >>>>>>>>>>>>>>>> close the producer side, without notifying the downstream >>>>>>>>>>>>>>>> about this. The example early in the thread uses multiple >>>>>>>>>>>>>>>> channels, with one channel being used to signal that the >>>>>>>>>>>>>>>> producers should exit. Channels aren't really the right model >>>>>>>>>>>>>>>> for this, you want a thread safe flag of some sort. For >>>>>>>>>>>>>>>> example: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> var exitFlag uint64 >>>>>>>>>>>>>>>> func producer(chan data int, wg *sync.WaitGroup) { >>>>>>>>>>>>>>>> defer wg.Done() >>>>>>>>>>>>>>>> for { >>>>>>>>>>>>>>>> shouldExit := atomic.LoadUint64(&exitFlag) >>>>>>>>>>>>>>>> if shouldExit == 1 { >>>>>>>>>>>>>>>> return >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> chan <- rand.Intn(100) >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Here's 10 producers and 3 consumers sharing a channel and >>>>>>>>>>>>>>>> closing it safely upon receiving an exit flag: >>>>>>>>>>>>>>>> https://play.golang.org/p/RiKi1PGVSvF >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- Marcin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Aug 28, 2019 at 11:29 AM Leo Lara >>>>>>>>>>>>>>>>> <l...@leopoldolara.com> wrote: >>>>>>>>>>>>>>>>> I do not think priority select is *necessary*, it could be a >>>>>>>>>>>>>>>>> nice addition if the performance does not change. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wednesday, August 28, 2019 at 8:27:36 PM UTC+2, Leo Lara >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> From the article: """To bound more the problem, in my case, >>>>>>>>>>>>>>>>>> you control the writers but not the readers""" >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So what I was trying to do was to be able to close, with >>>>>>>>>>>>>>>>>> mutiple writers, while being transparent for the readers. >>>>>>>>>>>>>>>>>> The readers only need to read as usual form the channel. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> For example, if you want to write a library where the user >>>>>>>>>>>>>>>>>> just reads from a channel, this is an approach I found where >>>>>>>>>>>>>>>>>> the user of the lirbary deos nto have to do anything >>>>>>>>>>>>>>>>>> special. Of course, there might be another solution, but if >>>>>>>>>>>>>>>>>> you need to modify the reader we are talking about a >>>>>>>>>>>>>>>>>> different problem. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Cheers!! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert >>>>>>>>>>>>>>>>>>> Engels wrote: >>>>>>>>>>>>>>>>>>> A better solution is to wrap the writes using a RWLock, >>>>>>>>>>>>>>>>>>> grab the read lock for writing, and the Write lock for >>>>>>>>>>>>>>>>>>> closing. Pretty simple. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Just encapsulate it all in a MultiWriterChannel struct - >>>>>>>>>>>>>>>>>>> generics would help here :) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>> From: Leo Lara >>>>>>>>>>>>>>>>>>> Sent: Aug 28, 2019 11:24 AM >>>>>>>>>>>>>>>>>>> To: golang-nuts >>>>>>>>>>>>>>>>>>> Subject: [go-nuts] Re: An old problem: lack of priority >>>>>>>>>>>>>>>>>>> select cases >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This is connected with my article: >>>>>>>>>>>>>>>>>>> https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I think there I show it is possible to workaround that >>>>>>>>>>>>>>>>>>> limitation using standard Go tools. Of course, the code >>>>>>>>>>>>>>>>>>> would be simple with priority select, but also perhaps >>>>>>>>>>>>>>>>>>> select would become less efficient. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> The old thread: >>>>>>>>>>>>>>>>>>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Go channels are flexible, but in practice, I often >>>>>>>>>>>>>>>>>>>> encountered some situations in which channel are hard to >>>>>>>>>>>>>>>>>>>> use. >>>>>>>>>>>>>>>>>>>> Given an example: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> import "math/rand" >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> type Producer struct { >>>>>>>>>>>>>>>>>>>> data chan int >>>>>>>>>>>>>>>>>>>> closed chan struct{} >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> func NewProducer() *Producer { >>>>>>>>>>>>>>>>>>>> p := &Producer { >>>>>>>>>>>>>>>>>>>> data: make(chan int), >>>>>>>>>>>>>>>>>>>> closed: make(chan struct{}), >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> go p.run() >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> return p >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> func (p *Produce) Stream() chan int { >>>>>>>>>>>>>>>>>>>> return p.data >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> func (p *Producer) run() { >>>>>>>>>>>>>>>>>>>> for { >>>>>>>>>>>>>>>>>>>> // If non-blocking cases are selected by their >>>>>>>>>>>>>>>>>>>> appearance order, >>>>>>>>>>>>>>>>>>>> // then the following slect block is a perfect use. >>>>>>>>>>>>>>>>>>>> select { >>>>>>>>>>>>>>>>>>>> case(0) <-p.closed: return >>>>>>>>>>>>>>>>>>>> case p.data <- rand.Int(): >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> func (p *Produce) Clsoe() { >>>>>>>>>>>>>>>>>>>> close(p.closed) >>>>>>>>>>>>>>>>>>>> close(p.data) >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> func main() { >>>>>>>>>>>>>>>>>>>> p := NewProducer() >>>>>>>>>>>>>>>>>>>> for n := p.Stream() { >>>>>>>>>>>>>>>>>>>> // use n ... >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If the first case in the select block in the above example >>>>>>>>>>>>>>>>>>>> has a higher priority than the second one, >>>>>>>>>>>>>>>>>>>> then coding will be much happier for the use cases like >>>>>>>>>>>>>>>>>>>> the above one. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> In short, the above use case requires: >>>>>>>>>>>>>>>>>>>> * for receivers, data streaming end is notified by the >>>>>>>>>>>>>>>>>>>> close of a channel. >>>>>>>>>>>>>>>>>>>> * for senders, data will never be sent to closed channel. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> But, as Go 1 doesn't support priority select cases, it is >>>>>>>>>>>>>>>>>>>> much tedious to implement the code >>>>>>>>>>>>>>>>>>>> satisfying the above listed requirements. The final >>>>>>>>>>>>>>>>>>>> implementation is often very ugly and inefficient. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Does anyone else also experience the pain? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> 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 golan...@googlegroups.com. >>>>>>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>>>>>> https://groups.google.com/d/msgid/golang-nuts/b284f880-034a-4721-8686-ef48d3e2c14c%40googlegroups.com. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> 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 golan...@googlegroups.com. >>>>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>>>> https://groups.google.com/d/msgid/golang-nuts/aeb38a0a-8268-42d7-a8eb-ce5ef01c5380%40googlegroups.com. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> 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 golan...@googlegroups.com. >>>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>>> https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LvcUhUvrZb_8AKYWj0A%2Bqd5LKBPmbz-RVBb%3DJn_gNZE6w%40mail.gmail.com. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> 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 golan...@googlegroups.com. >>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>> https://groups.google.com/d/msgid/golang-nuts/CANgi337s1Low95QvqJUAOTsqcVji7uMQ_jr%3DFftpt2uMz5_XSQ%40mail.gmail.com. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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 golan...@googlegroups.com. >>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>> https://groups.google.com/d/msgid/golang-nuts/a5cff3f8-cc1c-4719-9f2f-7b9c31086f6a%40googlegroups.com. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 golan...@googlegroups.com. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/d/msgid/golang-nuts/4bf95bb2-33ed-46ed-9436-48df1072914f%40googlegroups.com. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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 golan...@googlegroups.com. >>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/d/msgid/golang-nuts/d155dcf6-7c01-4f7e-b408-eef9903cd837%40googlegroups.com. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 golan...@googlegroups.com. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/d/msgid/golang-nuts/74653e49-f374-4ac8-998e-fd874cdf6bd4%40googlegroups.com. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 golan...@googlegroups.com. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/d/msgid/golang-nuts/3d75a129-efee-402f-aafa-9fe76af4e789%40googlegroups.com. >>>>>>> >>>>>>> -- >>>>>>> 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 golan...@googlegroups.com. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/golang-nuts/dfdf8905-f740-434c-a293-d801de4f71dc%40googlegroups.com. >>>>> >>>>> -- >>>>> 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 golan...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/golang-nuts/ffd06e6e-fb00-400e-ad5f-5f23d27025f7%40googlegroups.com. >>> >>> -- >>> 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 golan...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/dd5a26b4-b080-4dd1-801b-ff59eccf9940%40googlegroups.com. > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/fc0de346-f93e-4458-b301-1c893d24efa3%40googlegroups.com. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/978008A2-4C26-4197-893C-BA4E97CB2A82%40ix.netcom.com.
