[Stackless] Stackless API

Tom Locke tom at livelogix.com
Fri Jan 30 05:33:12 CET 2004

Hi All,

I can see this is going to be a vigorous debate, but unfortunately, I'm
too rushed off my feet right now to really engage in properly, so
apologies if I don't follow up on some of the ideas I've posted.

A couple of comments though:

Me> I think we need a some kind of syncing primitive that is lower-level
Me> than a channel. Maybe a good old semaphore?

Bob> Uh, why?  I can't think of something that a semaphore would bring
Bob> that can't already be done with channels.

Oh - just because semaphores can be very cheap. There are some new
high-level syncing facilities I'd like to have, and these things can
often be built much more cheaply out of something low-level like a
semaphore, than they can out of channels.

I agree - we can do everything already with channels.

Me> I guess you'll need to store the return value somewhere, in case the

Me> tasklet finishes before the call to wait(). Maybe this should be 
Me> visible, as in:

Having slept on this, I think its much cleaner to have the return value
returned by a wait() call. You always have to call wait() anyway (or
poll tasklet.alive), or you may hit a race hazard.

Arman> The problem with this model is that you have a single global
Arman> scheduler.

Not true. Yes the kernel always calls the scheduler I installed, but
from there I can write my own strategy to delegate to any number of
schedulers. I can also add a field to my tasklets, so that each tasklet
references the scheduler that it is managed by. The essence of good API
design, is to make the API as simple as possible, whilst making it
flexible enough to be used in a wide variety of ways.


Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list