[Stackless] Google's new Go programming language
andrewfr_ice at yahoo.com
Mon Nov 23 19:46:41 CET 2009
--- On Mon, 11/23/09, Jeff Senn <senn at maya.com> wrote:
> Unfortunately that seems to create a race condition
> (opposed to the implementations in other environments where the
>"select-like-operation" actually pops off the message). [Unless you also >propose a non-blocking receive...which would have other problems....
> I haven't been following this thread completely...]
> Imagine the tasklet interrupted (by someone else receiving
> from the same channel)
> between the select and the following .receive(...)
Thanks for pointing this out. I thought about this. Select is a
tough function. And it is looking like just returning one channel
is the best strategy. I am still working things through.
If my understanding is correct, if an available channel is ready,
the scheduler immediately make the selectable() tasklet current and
it returns. Certain race conditions can be avoided if the select()
action is not interruptible.
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.
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.
AF> I understand your minimalist approach towards Stackless. However
AF>I think Stackless can evolve only so far without actual
AF>changes to the scheduler. Priorities involved a change to
AF> the scheduler. Again, I
JS> I do agree with this...
More information about the Stackless