[Stackless] multiple channel waits

Christian Tismer tismer at tismer.com
Fri Aug 16 04:31:47 CEST 2002

Sam M. Rushing wrote:

>>Aaron Watters wrote:

>>>>Multiple channel wait is hard for me to understand completely.
>>>>I want to do it right, once and forever. I need to do a KQueue
>>>>like formulation. KQueue is unbeatable. 

>>>We're opposites.  KQueue is hard for me to understand.  Multiple
>>> channel waits are easy.

>>Sure. This is since they are easy and wrong.

> All right, I think I'm confused now.  I didn't see this as a big
> problem...
> I thought a multi-channel-wait was very similar to a condition variable.
> Which is easy to do with coroutines, and should be easy to do with
> channels.

I think we might talk different problems here.
Notifying many things on one condition is simple.
What I'm concerned about is how to have one
thing wait on very many conditions (channel activity)
effectively. That's basically what KQueue solves.

> You would have multiple threads block waiting on a condition,
 > and some other thread will come along and wake up one or more
 > of them.  Couldn't this just be done with a channel that waits
 > for an integer - telling it how many to wake up?

Yes, looks right. From the event's POV it is just that.

I think I introduced a hard restriction by my data structures.
Channels have a queue of tasklets. The tasklets are chained
to each other, which is very efficient. But it also means
that a tasklet can be in only one chain at any time.

For multiple containment, I need something better. Probably
additional containers. (Is that something called "list" ? :-)
Well, I tried to avoid all array stuff which needs to shrink
and grow.
Maybe I should think it over, find out what must contain what
and what must be reachable how, and then get it right?

Does a tasklet contain all the channels which it is waiting on?
Or does a channel contain all the tasklets which are waiting on it?
And when multiple tasklets wait on multiple channels, creating
an arbitrary set of subsets by this, how do I do that?
Or, where should I set the restrictions, what makes sense.

I have the slight idea that I'm doing the wrong thing:
Trying to *be* kqueue, instead of using it.

> -Sam
> p.s. Chris, if you need to get a handle on kqueue, there's a much
> simpler version of the scheduler etc... in the 'bench'
 > subdirectory.  The C++ version is more filled out (the dispatcher
 > mechanism supports kqueue, poll, and select), whereas the C version
 > is kqueue-only.  We discarded the C++ version because
> libcoro didn't get along with C++ exceptions (something that
 > should sound familiar to you! 8^)

On the exceptions problem: Well, one could catch them
and map them into Python exceptions, no?

So it is the one in bench which is actualy used?

Oh, I'm tired - later - cheers - chris

Christian Tismer             :^)   <mailto:tismer at tismer.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  pager +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 mailing list
Stackless at www.tismer.com

More information about the Stackless mailing list