multithreading - In Go what happens if you write to closed channel? Can I treat channels as deterministic RE destruction? -

okay warning me subjective title please let me explain. right i'm looking @ go, i've read spec, watched few io talks, looks interesting have questions.

one of favourite examples select statement listened channel came "doafter()" or something, channel send @ given time now.

something (this wont work, pseudo-go if anything!)

to := time.doafter(1000 * time.ms) select:     case <-to:         return nil //we timed out     case d := <-waitingfor:         return d 

suppose thing we're waiting happens fast, function returns , isn't listening to more, happens in doafter?

i , know ought not test channel, example

if(chantosendtimeouton.isopen()) {     chantosendtimeouton<-true } 

i how channels sync places, example possible function above return after isopen() test before sending of true. against test, avoids channels - hide locks , whatnot.

i've read spec , seen run time panics , recovery, in example recover? thing waiting send timeout go routine or "object" of sorts? imagined "object" had sorted list of things had send things after given times, , it'd append timeafter requests queue in right order , go through it. i'm not sure that'd opportunity recover.

if spawned go-routines each own timer (managed run-time of course, threads don't block time) chance recover?

the other part of question lifetime of channels, imagine they're ref counted, able read ref-counted, if nothing anywhere holds readable reference destroyed. i'd call deterministic. "point-to-point" topologies can form if stick towards go's "send stuff via channels, don't access it"

so here example, when thing wants timeout returns to channel no longer read anyone. go-routine pointless now, there way make return without doing work?

example:

file-reading go routine has used defer close file when done, can "sense" channel supposed send stuff has closed, , return without reading more?

i'd know why select statement "nondeterministic" i'd have quite liked if first case took priority if first , second ready (for non-blocking operation) - wont condemn that, there reason? what's implementation of this?

lastly, how go-routines scheduled? compiler add sort of "yielding" every many instructions, thread running switch between different goroutines? can find info on lower level stuff?

i know go touts "you don't need worry this" know things write hide (that c++ thing) , reasons why.

if write closed channel, program panic (see http://play.golang.org/p/ku7mlrfqsx example). potentially catch error recover, being in situation don't know whether channel writing open sign of bug in program. send side of channel responsible closing it, should know current state. if have multiple goroutines sending on channel, should coordinate in closing channel (e.g. using sync.waitgroup).

in time.doafter hypothetical, depend on whether channel buffered. if unbuffered channel, goroutine writing timer channel block until read channel. if never happened, goroutine remain blocked until program completed. if channel buffered, send complete immediately. channel garbage collected before read it.

the standard library time.after behaves way, returning channel 1 slot buffer.