Twisted: 1 thread in the reactor pattern
exarkun at twistedmatrix.com
exarkun at twistedmatrix.com
Wed Sep 23 10:57:28 EDT 2009
On 06:08 am, jacopo.pecci at gmail.com wrote:
>I am diving into Twisted and Perspective Broker (PB) in particular and
>I would like to understand more about what happens behind the
>curtains.
>Say I have a client and a server on two different machines, the server
>gets callRemote() 19s in an asynchronous way, these requests are parked
>in a queue and then served sequentially (not in parallel 13 correct me
>if I am wrong).
Since, as you point out below, there is only one thread, the remote
methods can only be invoked one at a time.
However, rather central to the asynchronous operation of Twisted
libraries and applications, the remote method itself may return before
the remote call has been completely serviced. So while only one remote
method will run at a time, each of the two remote calls may run
concurrently at some point before they are responded to.
>If everything is implemented in a single thread, how
>is it possible that while the processor is engaged in the processing
>triggered by callRemote() 19s at the same time the reactor is ready to
>listen/accept new events and put them in a queue? To me it looks like
>there should be at least 2 processes, one for the reactor and on for
>the rest.
It isn't possible. While the remote methods are running, other events
are not being serviced. This is what is meant when people describe
Twisted as a "*cooperative* multitasking" system. Event handlers (such
as remote methods) run for a short enough period of time that it doesn't
matter that the reactor is prevented from accepting new connections (or
what have you) for the duration of their execution.
Jean-Paul
More information about the Python-list
mailing list