Btw, the removing of the GOMAXPROCS causes things to execute serially- which is fine according to the spec - but it does make demonstrating certain concurrency structs/problems pretty difficult.
> On Sep 1, 2019, at 7:05 AM, robert engels <reng...@ix.netcom.com> wrote: > > The point about ‘mu’ is valid. Rather than ‘closed’, it should really be an > ‘error’ given the situation - as it is more applicable to the operation > failures (as a black box IO component). > > >> On Sep 1, 2019, at 6:46 AM, Robert Engels <reng...@ix.netcom.com> wrote: >> >> As I pointed out in another reply, I am fairly certain the atomic operations >> must be valid in these cases due to the happens before relationship of them >> and mutexes. >> >> I don’t agree that returning the channel is a proper design, it breaks the >> encapsulation. Technically mine could use multiple channels behind the >> scenes - yours cannot. >> >>> On Sep 1, 2019, at 3:06 AM, roger peppe <rogpe...@gmail.com> wrote: >>> >>> The problem seems to be that you're using runtime.GOMAXPROCS. The fact that >>> using GOMAXPROCS causes a deadlock is probably a bug, but it's an easy one >>> to work around - just don't call it :) >>> >>> FWIW here's a version of your code that I'd consider a little more >>> idiomatic. >>> >>> https://play.golang.org/p/ufLXXX1zbrn >>> >>> - it reports true when an operation succeeds rather than when it fails >>> (think reading from a channel or from a map). >>> - it removes the unnecessary (and probably wrong) atomic load >>> - it allows direct access to the channel for reading (and select etc) - no >>> need to hide it behind the Read method. >>> - mutex fields are very often named "mu" >>> >>> cheers, >>> rog. >>> >>>> On Sat, 31 Aug 2019 at 23:13, robert engels <reng...@ix.netcom.com> wrote: >>>> The code at https://play.golang.org/p/9ZdPVvwyaYK >>>> >>>> should not deadlock. But it reports: >>>> >>>> fatal error: all goroutines are asleep - deadlock! >>>> >>>> But if you look at the stack traces, you see multiple routines (sampled) >>>> like: >>>> >>>> goroutine 1 [sleep]: >>>> runtime.goparkunlock(...) >>>> /usr/local/go/src/runtime/proc.go:307 >>>> time.Sleep(0x3e8, 0x0) >>>> /usr/local/go/src/runtime/time.go:105 +0x1c0 >>>> main.main() >>>> /tmp/sandbox327672725/prog.go:81 +0x140 >>>> >>>> goroutine 5 [sleep]: >>>> runtime.goparkunlock(...) >>>> /usr/local/go/src/runtime/proc.go:307 >>>> time.Sleep(0x1, 0x0) >>>> /usr/local/go/src/runtime/time.go:105 +0x1c0 >>>> main.producer(0x430150, 0x40a0e0) >>>> /tmp/sandbox327672725/prog.go:49 +0x60 >>>> created by main.main >>>> /tmp/sandbox327672725/prog.go:73 +0xe0 >>>> >>>> These routines are asleep, not blocked. They will awake from sleep >>>> (eventually) - so there cannot be a deadlock. >>>> >>>> I am assuming this is a limitation of the Go playground back-end, but I >>>> can’t see it documented anywhere? Also, I’m not sure why this limitation >>>> would exist, since if all the routines are asleep or blocked, it is >>>> consuming no resources. >>>> >>>> Ideas? >>>> >>>> -- >>>> 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/C7B46199-05EA-47C1-9594-200E2DD36F99%40ix.netcom.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/AC9DEEBD-37DF-49FA-8171-E45418584697%40ix.netcom.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/C248F20A-88EC-4C36-9931-C9F35585206A%40ix.netcom.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/915EA1FF-2B66-4473-9082-6FCC1E399B2D%40ix.netcom.com.
