Event Driven programming - Doubts
Bryan Olson
fakeaddress at nowhere.org
Tue Dec 23 00:13:01 EST 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".
http://docs.python.org/library/select.html
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
description.
--
--Bryan
More information about the Python-list
mailing list