Event Driven programming - Doubts

Bryan Olson fakeaddress at nowhere.org
Tue Dec 23 06:13:01 CET 2008

Kottiyath wrote:
> [...] I have not yet understood the implementation of
> deferred. I went through a lot of tutorials, but I guess most places
> they expect that the user already understands how events are
> generated. The tutorials mention that there is no more threads once
> twisted is used.
>     My question is as follows:
>     I have not understood how the callbacks are hit without (a)
> blocking the code or (b) having new threads.
> The usual example given is that of a program waiting for data coming
> through a socket. In the tutorials, it is mentioned that -in an event
> driven program, we schedule the code to hit when the remote server
> gets back to us - .
> Now, my question is - somebody has to still wait on that socket and
> check whether the data is received, and once all the data is received,
> call the appropriate callbacks.
> Is twisted creating a micro-thread which just waits on the socket and
> once the data is received, calls callFromThread for it to run on the
> main loop?

No. Event-driven frameworks are built upon some system call that waits 
for events from multiple sources at once. The Python standard library 
exposes several such calls, the most portable of which is select(), in 
the module also named "select".


So how is something like deferred implemented? When you schedule action 
on your socket, you are telling the framework to include your socket in 
in subsequent calls to select(), until the socket selects as ready.

The framework keeps a single global list of sockets on which clients are 
waiting, and from this list it builds the select() parameters. A single 
call to select() waits on behalf of all the callbacks. The select() call 
returns a list of sockets ready for I/0; the framework iterates over the 
ready list, invoking the corresponding callbacks one by one. After the 
last callback returns, the framework loops back to select() again.

select() is not the only call to do multi-source I/O, and I'm not an 
expert on these frameworks, so take the above as a simplified general 


More information about the Python-list mailing list