On 03/02/2012, at 4:31 AM, Gleb Peregud wrote: > Looks like Felix has processes/threads/fibers similar to Erlang processes.
There is some similarity, but Erlang is exclusively message passing, whereas Felix supports shared memory. In fact, fibres represent logical threads of control in the same memory environment, and are interleaved under user program control so that shared memory access at the lower levels is guaranteed to be safe. Erlang does this interleaving as well, but it's an implementation detail, and deliberately: it is what allows you to move some of the processes into real OS processes or even "off shore" to other machines, without any code changes. You can't do that with Felix fibres or pthreads. In fact, Felix already has asynchronous socket I/O where the client code blocks fibres but not pthreads. The webserver on the website uses that: in theory it can support massive numbers of connections at the highest possible performance (that can be delivered by a single CPU). Context switching fibres outperforms OS pthread context switches, probably at least 1000 times faster, and there is no effective limit on the number of fibres (they're very lightweight, basically a single pointer is kept in a list). The main problem is that this is a stream model, like the underlying sockets support and that basically sucks: there's no framing. Which means applications have to agree on a framing protocol to communicate since most applications require messages not streams (even streaming protocols!) 0MQ solves that problem nicely by providing a "standardised" framing protocol, and at the "Posix API like" level. My problem is to make that work with fibres, but that has nothing to do with the thread safe API proposal. I just like theoretical challenges :) The ts proposal is more like: if you really want to get 0MQ into Posix you probably need to have a thread safe variant. No one is going to accept something that isn't at least optionally thread safe these days. It is OK for "msg" objects because they're transient in some sense IMHO, but there needs to be support for thread safe sockets (even if no one who know what they're doing ever uses them!). Actually ts sockets as proposed may be very useful debugging, since it eliminates one kind of possible error, temporarily. -- john skaller [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
