Avoiding an error condition on more () when it would block is achieved by excluding the channel from the list of socket polled for output when the first producer in the channel’s output_fifo is stalled.

Developers don’t need to worry about producer stalling in an async_chat channel, because its writable () and handle_write () methods are carefully designed so that such error conditions do not occur. If the first producer is stalled, writable() will be false and more() won’t be called in the event loop.

If you do have to call more () somewhere else, independantly from the event loop, it will most probably be in an accumulator like the composite producer when it globs output. Then, but it is a rare case, you will have to check for the producer beeing stalled.

Regards,

more() should raise an exception if it is going to block. This is to avoid a race condition.

It is the old peek, and use pattern.

if producer_stalled():
# in this time between method calls the producer may not be stalled.
# meaning you miss a chance to call more()
more()

In practice it might not be an issue.

Here is the other way…
try:
bla = more()
except ProducerStalled:
print “moving on!”

I’d like to hear why it isn’t a race condition. Or if it is, why it doesn’t matter.

There are at least two reasons I can think of for not changing that interface into a “positive” one. The first is that one should not fix what ain’t broken. I found producer_stalled in the experimental section of Medusa sources and kept it as it was. The second reason is that use case of the interface is indeed a “negative” as found in the Async_chat.writable () method.

Anyway, thanks for the comment and suggestion.

eg. not producer_stalled() means that there is not not some more.

Maybe some_more() instead?