[zeromq-dev] Thread Safe sockets

[john skaller]

On 07/02/2012, at 7:41 PM, Nadav Samet wrote:

> 
> On Mon, Feb 6, 2012 at 5:16 PM, Martin Lucina <martin at lucina.net> wrote:
> 1) IMHO callbacks are evil and in 90% of cases should be
> eradicated :-) Of course if you've got a huge legacy code base then
> you're stuck with 'em, so it's a valid use case.
> 
> I'm not sure I follow, what's evil about callbacks?

The author of a callback is a slave: a callback is a subroutine.
Compare with a thread, which is a master.

The advantage of a master on a conventional machine is that data and control
are synchronised by the machine stack. In other words, the state you're in can
be partly determined from the program counter.

In  callback, if you have to do complex work you must manually construct
and manage both state and control.

To put this crudely, subroutines are inside-out threads.

To fully understand this, consider some simple C program that does
some I/O from files. Note careully you're reading and writing files,
you're the master.

Now, rewrite your program as a callback, which is called with data
from the file and/or which must return data to be written to the file.
Then you will understand why callbacks suck.

You will also understand a thing I call "control-inversion". Thats what you have to do
to convert a thread doing I/O into a callback driven by events (or vice-versa).

There are entirely mechanical rules for control inversion, but they're very hard
to follow for a human. [The Felix compiler does precisely this: it turns thread
like code into callbacks automatically].


> In particular, I am working on an RPC library on top of ZeroMQ. It spawns n threads, and whenever a request arrives it runs a user-supplied function (i.e. callback) on one of these threads. Are there alternative designs that I should consider?

Of course: you *read* the request from the socket. If you have only stateless processing,
meaning every request is entirely independent, a callback is fine. But if you have
state, then a thread doing a read of the request stream is better. For example,
any kind of session.

--
john skaller
skaller at users.sourceforge.net