I'd just like to point out that unix select() on sockets has the same kind of "problem." A select() call indicates that a recv() won't block. meanwhile someone else decides to recv() from that socket, before the caller of select() gets around to do that. This is not a race condition, it is just how select() is designed. It is up to the programmer to make sure that only a single sink is reading from that source.
If you have other tasklets receiving from the channels you are selecting from, then you are using a programming model designed to give you grief, whether you can construct an atomic select+receive or not. K > -----Original Message----- > From: [email protected] [mailto:stackless- > [email protected]] On Behalf Of Jeff Senn > Sent: 23. nóvember 2009 19:35 > To: Andrew Francis > Cc: [email protected] > Subject: Re: [Stackless] Google's new Go programming language > > > On Nov 23, 2009, at 1:46 PM, Andrew Francis wrote: > > > Still this doesn't avoid a second form of race - a select returns > > with a list. Instead of immediately manipulating a selectable > channel, > > the tasklet 1) calls schedule() 2) Does some action that causes the > > tasklet to block and allows another tasklet to perform a channel > > operation on the selectable channel, hence changing the situation. > > Yes, this is what I meant. > > > i.e > > > > channel = select([]) > > stackless.schedule() # dumb thing to do > > > > #meanwhile the channel's state changed > > request = channel.receive() > > > > Using select() this way, I would say tough luck to the programmer > that > > uses it in this fashion. And if this is a part of a language feature, > > it may never happen. > > Err... am I the only one who is interested in preemptive scheduling? > :-) > > Also note that even if you are *not* doing preemptive scheduling, that > a feature that requires that kind of programmer attention > is a classic trap for breaking code in horrible ways with what seems > like an innocuous (or non-local) change. > > Imagine: > > foo = select(...) > get_ready() > go(foo.receive()) > > And then later someone inserts something into the implementation of > "get_ready" > that can cause a schedule (or say, sends a messages down another > channel, > or....) > > A less error prone construct would be: > > chan, message = select_and_receive([chans,...]) > > > > > > > > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
