[Twisted-Python] Tie two event loops

Jean-Paul Calderone exarkun at divmod.com
Wed Jul 2 14:46:39 EDT 2008


On Wed, 2 Jul 2008 15:46:05 +0100, Paul Wilson <paulalexwilson at gmail.com> wrote:
>Hi all,
>
>I'm new to twisted but am having trouble getting my head around how to
>structure my application with this new approach.
>
>I'm creating a server that accepts client connections and then drives
>the client according to a simple, line-oriented protocol. The server
>sends the request (1 line), and receives a single lined result. I'd
>like the server to offer an API to generate the correct request lines
>to the client, and return the results (either blocking or
>asynchronously). So in effect, I have two event loops, one from the
>Network and one from whatever's sending the API requests (command
>line?).
>
>Can anyone offer any guidance on how to tie these two parts together?
>My instinct is to have the two event loops in separate threads and
>communicate through Queue.Queue, but that doesn't seem to follow the
>spirit of twisted. And I guess I'd have to somehow tell the reactor to
>poll the Queue object for requests, and then dispatch it to the
>relevant method to send out to the client. I've looked at
>threadedselectreactor but can't seem to find any decent documentation
>to even decide if it's write for what I want.
>
>Any advice would be much appreciated.
>

It's not very clear what the two different event loops are for.  You
suggest that the synchronous API might be used by the "command line",
but this doesn't necessarily require a synchronous API.  It's also not
clear if there is going to be a command line tool which is invoking this
API via Python function calls or if it will be talking to a server that
exposes some kind of network interface (since your other use case seems
to involve doing this, it might save you some work to just re-use that).

Another possibility is that the server process will have code running in
it which wants to access this functionality but wants a synchronous API.
My first suggestion is to forget about this and just use the asynchronous
API everywhere.  If that's too hard, then I suggest making two different
APIs.  This shouldn't be very hard (particularly since I think we're
talking about a function that takes a string and returns another string).
Then, code can just use the API that's right for it.

I don't know if this response has made any sense, because I really don't
feel like I understand the question.  If it didn't, maybe you can try to
clarify the question a bit, perhaps providing some examples (either in
English or in Python).

Jean-Paul




More information about the Twisted-Python mailing list