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 Stackless@stackless.com http://www.stackless.com/mailman/listinfo/stackless
