[Stackless] priority patch

Kristján Valur Jónsson kristjan at ccpgames.com
Wed Nov 4 22:18:31 CET 2009

Hello there.
Attached is a patch to the trunk stackless version, implementing tasklet "priority".
The motivation for this is to enhance the throughput of stackless-based IO solutions, and the performance of channel-based locks.

There are two priority levels:  'prority' and 'normal.'
The idea is that a "priority" tasklet will get priority over regular tasklets in the runnable queue.  A tasklet can have the 'priority' flag set, in which case it is always high priority, or else, have its boost() function called, in which case it will get high priority only once, on it s next insertion into the runnable queue (or immediately, if it is already runnable).  Once it is run, or removed from the queue, it falls back to normal.

The use case for this is to give additional priority for "interrupt" tasklets, such as those that receive IO events, without having to switch immediately to them.  Such a tasklet would get a boost() call, before being insert()-ed (e.g. by calling channel.queue.boost() before calling channel.send(None) for a channel with channel.balance=0).  Thus the calling tasklet continues, but the awoken tasklet will get put ahead all "normal" tasklets in the queue.  It will be put after any other high priority tasklets already there, however.

This is also useful for locks, in order to implement high-throughput locks (avoid lock-convoys) without the "switch immediately" semantics that a channel with priority == -1 haves.  The front most tasklet waiting for the lock can then have its priority boosted before being awoken, to be given the chance to grab the lock.

The patch is fairly simple.  I added a number of high-level functions to manipulate the runnable queue.  We actually have two queues, one which hangs off state->ts.current as before, and another at state->ts.priority.  That one is consulted whenever a new tasklet is moved up in state->ts.current to become the next active tasklet.

I used the oppertunity to visit those places in the code where state->ts.current was being manipulated, often with low-level constructs, and to try to understand, and straighten out the purpose of the code there, using proper functions instead of macros for list evaluation.

I've added a rudimentary test into the unittests for this.

If no one objects too strongly to this I'm hoping to get this accepted into the trunk.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20091104/e21a5f05/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: prioritypatch.rar
Type: application/octet-stream
Size: 6825 bytes
Desc: prioritypatch.rar
URL: <http://www.stackless.com/pipermail/stackless/attachments/20091104/e21a5f05/attachment.obj>

More information about the Stackless mailing list