[Stackless] Google's new Go programming language

[Kristján Valur Jónsson]

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: stackless-bounces at stackless.com [mailto:stackless-
> bounces at stackless.com] On Behalf Of Jeff Senn
> Sent: 23. nóvember 2009 19:35
> To: Andrew Francis
> Cc: stackless at stackless.com
> 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
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless