On 07/02/2012, at 7:41 PM, Nadav Samet wrote: > > On Mon, Feb 6, 2012 at 5:16 PM, Martin Lucina <[email protected]> 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 [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
