asynchat producer ready() method patch.
Wed, 18 Apr 2001 11:38:48 +1000 (EST)
Quoting Ted Shab <tshab@y...>:
> Saw this from the pipermail list. Has this patch been
> applied to the standard python distribution or is it
> pipermail specific? If the later, can you let me know
> where I might find the fix (I'm not really interested
> in pipermail).
Hmmm, someone is using this patch? Wow, (warm fuzzies :-). I'm Cc'ing this to
the medusa list incase anyone else is interested.
AFAIK, no-one was using this patch apart from one person experimenting with it.
There is nothing wrong with it, there just didn't seem to be much interest. I
don't believe it has been applied anywhere apart from in my own projects. I'm
hungry for any feedback on it and keen to support/promote it if there is
The patch is against medusa-src-20000601.tar.gz, and can be found in;
Note that parts of medusa are distributed with python (asyncore.py and
asynchat.py), and the relevant parts of the patch are designed to be compatible
with the components in the python distribution (ie, there are no introduced
dependancies and they are backwards compatible). I would like to think that the
changes introduced also clean up the code a bit and provide a useful
inheritance hirachy for producers. Performance heads might argue that the
inheritance hurts performance. Comments about that are welcome too :-)
The only tips about this patch from experience are;
- be aware of how ready() is meant to work. It must return true whenever a
producer is ready for more() to be called. That means when it has more data
_or_ the producer is finished. Calling more() when a producer is not ready() is
an error, and the producer base clases provided will raise an exception when
- beware of producers that already have ready() methods. The original medusa
had quite a few vestigial ready() methods that behaved incorrectly. The patch
includes changes to fix/remove these methods in medusa.
- a change in ready() status is not an event that will trigger select(). The
ready() method is called before select() inside the main polling loop. This
means a change in ready() status will not be immediately evaluated, but will be
delayed until the next iteration through the loop. If no events trigger the
select(), then this means it will be delayed untill the select() times out. The
simple solution is to use a short timeout value. The complex solution is to
make the change in ready() status trigger the select(), typicaly by putting an
async object inside the producer. Note that this behaviour also affects the
normal readable() and writeable() methods, but typicaly these change status as
a result of something that triggers select() so you don't notice.
ABO: finger abo@m... for more information.