asynchat producer ready() method patch.

[Donovan Baarda]

Quoting Ted Shab <tshab@y...>:

> Hello,
> 
> 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 
interest.

The patch is against medusa-src-20000601.tar.gz, and can be found in;

ftp://minkirri.apana.org.au/pub/python/

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 
this happens.

- 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.