[Twisted-Python] CONNECTION_LOST not an integer (docstring error?)
glyph at divmod.com
glyph at divmod.com
Fri Oct 3 19:25:46 EDT 2008
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
covers writeSomeData. Another rule of thumb is that the high-level
stuff is on explicitly specified interfaces, such as
Of course there are some low-level interfaces too, for example
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
>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).
More information about the Twisted-Python