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 <tapir....@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 golang-nuts+unsubscr...@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/F49B25BF-D39D-4D0A-B918-1811ABD5BD47%40ix.netcom.com.
