[Stackless-dev] Re: Stackless and the future

Christian Tismer tismer at stackless.com
Wed Apr 14 20:41:16 CEST 2004


Kristján V. Jónsson wrote:

> Yesterday, I was having fun implementing the pthreads synchronization 
> primitives for stackless.  I was doing this using channels, waking up 
> sleepers with a send(None).  Then I realised that channels have a 
> problem:  They cause targeted scheduling.

Yes. This is what CCP loved the most, because it made mouse
handlers very reactive. But one size doesn't fit all :-)

> When I send on a channel, the context will be switched immediately (or 
> after blocking) to a receiver.  This means that if I implement a mutex 
> using a channel, and do a send() when unlocking, control will 
> immediately be given to the waiting tasklet.

This might be a deficiency, but I think it is quite easy to get
along with: If your mutex code does a schedule(), right after
being unlocked, it will become the last runnable in the queue.

> And so, nothing will 
> happen in the system until all tasklets waiting for this mutex have 
> finished.  Currently I fix it using a delayed send by creating a tasklet 
> for this purpose and waiting for it to be scheduled in its own good 
> time.  But it got me thinking that maybe channels shouldn´t be the basic 
> synchronization mechanism in stackless.   Maybe this is what you have 
> been talking about lately, with greenlets, and all that.  But here´s my 
> suggestion.

Channels by themselves are a fine thing, since they do real
blocking. What it bad is probably the default decision what
they should do when data is available. This is all going to
be virtualized and definable.

> Basically I think that the most primitive syncrhonization primitives 
> should be to allow one to make a tasklet runnable or not.  I know that 
> this is now implemented by chaining them either in the run queue or on 
> channels. maybe this could change.  But a tasklet could go to sleep with 
> something like
> stackless.getcurrent().runnable(False)
> stackless.yield()
>  
> A tasklet could be made runnable again by another tasklet, thus placing 
> it in the runnable queue.

Discussions on the sprint have gone into the opposite direction:
There should be no runnables queue at all, which makes the greenlets.

> yield() could take as an argument a runnable tasklet if we want to 
> explicitly yield to that one at this point.   This could be used to 
> implement channels in their current form, or to implement a custom 
> scheduler.
>  
> channels could be implemented with a regular python list, and the 
> runnable() tasklet method and the yield() method.
>  
> Basically, I think that the channels carry to much scheduling semantics 
> along with them to work as the primary synchronization object in 
> stackless.  (I did write a DelayedChannel(stackless.channel) that 
> delegates each send() to a worker tasklet, but it does seem a bit over 
> the top.

I do agree that there are too many decisions "under the hood".
But I don't know exactly which direction to go, so I cc'ed
the stackless list for discussion.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


_______________________________________________
Stackless-dev mailing list
Stackless-dev at stackless.com
http://www.stackless.com/mailman/listinfo/stackless-dev



More information about the Stackless-dev mailing list