[Stackless] Re: Stackless API

Christian Tismer tismer at stackless.com
Tue Feb 3 05:28:08 CET 2004

Esteban U. Caamano Castro wrote:
> Bob Ippolito wrote
>>I think that exceptions on channels are more useful
>>than just closure 
>>notification, but I think the implementation should
>>be changed to make 
>>these exceptions travel out-of-band from the data.
> I suppose by 'out-of-band' you are making the point
> that only send_exception(), and not send(), should
> raise at the other end. If it's that, then it's fine;
> everyone seems to agree.

Ok! Now after I undertand exactly what people want,
I actually *am* interested in implementation bints :-)

> Now, *implementation wise* I think it's advisable that
> exceptions which are meant to explode actually travel
> along with the data. This sounds like the simplest way
> to make sure that they will get appropiately queued. 
> My assumption is that if the channel has 3, 2, 1
> waiting to be sent, and you send_exception(*boom*),
> you should get 3, 2, 1, *boom* at the other end. This
> is current behaviour.

On thing could be to queue up tuples all the time, where
a second element in the tuple tells me whether to raise
an exception or not.
But that seems to make "normal" channel operation unnecessary
I gues that raising a bomb on a channels is not the most
common action unless you are the roadrunner coyote,
so maybe it would be most efficient to use a special
object as a marker flag? This object could be solely visible
to channels.
Other proposals?

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 mailing list
Stackless at stackless.com

More information about the Stackless mailing list