[Stackless] Stackless API (Custom Scheduling)

[Bob Ippolito]

On Jan 29, 2004, at 2:06 AM, Tom Locke wrote:

> OK... what about various ideas about custom scheduling? Here's my
> proposal. (I'm thinking as I go here).
>
> A module property stackless.scheduler, to which one can assign an
> object.
>
> This object should provide a certain interface. Here, to describe the
> interface, is a simple round-robin implementation:
--cut--
> You can implement almost any strategy with this approach. E.g. you 
> could
> do Bob's "sub-watchdogs".
>
> The scheduler API could be extended to support non-busy timeouts. We
> could add a method 'blockUntil(tasklet, wakeTime)'

I've had a few thoughts:
(a) make some scheduler type whose instances are a factory (or at least 
a bag for) for tasklets and channels, give it a "run_watchdog" (that 
could be run from inside another scheduler, I suppose, instead of just 
the main tasklet).  The module level tasklet and channel factories 
could essentially be associated with a "global" instance of this 
scheduler object.

(b) make the set_schedule_callback and set_channel_callback methods 
more useful -- let them actually change the behavior with their return 
value!  You could assign them both to instance methods of a "scheduler 
object" and you probably wouldn't need a baked-in one to do it (though 
you might want one for performance, or whatever).

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

Uh, why?  I can't think of something that a semaphore would bring you 
that can't already be done with channels.
sem_getvalue -> channel.balance
sem_post -> channel.send
sem_wait -> channel.receive
sem_trywait -> check channel.balance then channel.receive if you know 
it won't block

I'm ignoring stuff like semop and semctl, because they don't really 
seem that useful to me (from Python, in Stackless).

> Once this, and the scheduler are in place, I feel methods like 
> capture()
> and become() should be removed. These methods scare me :) They look 
> like
> they exist to expose cool things you can do as a result of the current
> implementation strategy, but are semantically hair-raising.

All I know is that they make the interpreter misbehave, I have no idea 
what use they have either :)

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
URL: <http://www.stackless.com/pipermail/stackless/attachments/20040129/0d0ed699/attachment.bin>
-------------- next part --------------
_______________________________________________
Stackless mailing list
Stackless at stackless.com
http://www.stackless.com/mailman/listinfo/stackless