[Twisted-Python] CONNECTION_LOST not an integer (docstring error?)

[glyph at divmod.com]

On 1 Oct, 10:37 pm, mforbes at physics.ubc.ca wrote:
>>On Oct 1, 2008, at 3:44 PM, Jean-Paul Calderone wrote:

>>However, it's a very low-level API and since it isn't intended to be
>>used by application code, it doesn't seem like a very high priority
>>to make it less confusing.
>
>By the way, is there any convention by which "high level" API  routines 
>are distinguished from "low level" routines?  It is really  not that 
>clear from the docs... (writeSomeData comes first in the  listing etc.)

writeSomeData only comes first if you're looking at the documentation 
for "Connection", which is itself kind of an internal thing.  The 
internals definitely aren't as cleanly separated from the public / 
application interface as they should be, but a good rule of thumb is 
that high level stuff is what's covered in the tutorial documentation. 
For example, none of 
<http://twistedmatrix.com/projects/core/documentation/howto/producers.html>, 
<http://twistedmatrix.com/projects/core/documentation/howto/servers.html>, 
or 
<http://twistedmatrix.com/projects/core/documentation/howto/clients.html> 
covers writeSomeData.  Another rule of thumb is that the high-level 
stuff is on explicitly specified interfaces, such as 
<http://twistedmatrix.com/documents/8.1.0/api/twisted.internet.interfaces.ITransport.html>. 
Of course there are some low-level interfaces too, for example 
<http://twistedmatrix.com/documents/8.1.0/api/twisted.internet.interfaces.IWriteDescriptor.html> 
but their documentation is typically not as expository.

But the ultimate rule is that high-level interfaces are convenient, and 
the low-level ones (as you have noticed about writeSomeData) are not :).
>I know that and am using callFromThread: The reason I am having bad 
>behavior is because the socket is backing up.  Once I put in the  logic 
>to throw out data, it works fine... but the lack of reactor  support 
>concerns me somewhat.

What do you mean by "backing up"?  That doesn't really make sense.  When 
a transport "backs up" in Twisted, it just allocates a larger and larger 
buffer to store the data that is queued to be sent.

And what is the "lack of reactor support" you're talking about?  It 
seems to me that the reactor supports everything you need.
>I don't want the computation to stop,  but think I could put an 
>intermediate "push producer" that stops by  discarding the data.

I don't *really* understand what you're trying to accomplish here; it 
soudns to me like you actually want a pull producer that just always 
sends the latest state in resumeProducing(), assuming it's always 
changing.  Of course the "every 30 minutes" timeframe confuses that 
somewhat.  However, using some kind of producer is definitely the way to 
go.
>Is there a simpler way to do this all with twisted without using 
>threads? (The main goal is having an extremely minimal set of hooks 
>for the people writing the computational code, and having the 
>computational code run as fast as possible.)

You could use subprocesses.  Valentino Volonghi is working on a 
convenient process-pool for use with Twisted: 
<https://launchpad.net/ampoule/>.  I don't think that would actually 
help you that much though, since you'd still need to have application- 
specific buffering logic (it's a slightly unusual requirement to throw 
away intermediary state depending on the buffer saturation).