[Stackless] One-way channel pairs
oren-sl at hishome.net
Sun Feb 8 11:10:19 CET 2004
On Sun, Feb 08, 2004 at 08:13:25AM +0100, Christian Tismer wrote:
> > def close(self):
> > """ The real implementation should also prevent further writing
> > to the channel and ensure that StopIteration will be raised for
> > all receivers, not just one! """
> > if self.queue:
> > self.send_exception(StopIteration)
> It will!
This means that .close() will not send StopIteration into the channel as
data but set a flag on the channel. What about other exceptions? Should
they also be raised for every reader of the channel? Just for the first
one? Should an exception also close the channel?
> >class receive_only_channel:
> >class send_only_channel:
> Do you think it would make sense to make these into the
> basic channel implementations, or do you think we should
> keep the current ones (with extension) and build your's
> upon them?
My implementation uses 3 objects: the underlying channel object and two
wrappers. It could be nice to cut it down to 2, but that would probably
require some change to the the channel object.
> Do you think efficiency would be reasonably better?
> Do you think the C implementation could get simpler?
A C implementation is definitely preferred.
> If so, I'd like to try it!
Hmmm... I just realized that there is another case that channel2()
should handle. Let's say a tasklet blocks on writing to a channel
because there is no currently listening tasklet but there are still
references to the receive side of the channel, and *then* the reference
count to the receive side goes to zero. I think the sending side should
unblock and raise an exception. In my current implementation will just
I'm not even sure how to implement that. The other direction is
relatively simple: just send as many exceptions down the pipe as there
are listeners in the queue. But I don't think there is an equivalent way
to send exceptions *up* the pipe to the senders to inform them that there
isn't, and there will never be, a listener on this channel.
P.S. take a look at http://tothink.com/python/dataflow
Stackless mailing list
Stackless at stackless.com
More information about the Stackless