[phintjens]

It's great to get feedback on the talk. Impossible to even introduce 0MQ properly in 10 minutes, so this presentation was really just to drive discussion. I'd apologise for the polemical title but that's just how I talk.

To some of the comments here...

- Parallel programming may be taught in CompSci courses, for sure, and it's a popular use for 0MQ, but (a) it's not applied to mainstream application development, and (b) it is not designed to scale to networks of any size.

- The Actor model is not key to building a successful message-based concurrent application, but it's a good example, and helps people understand that there are alternatives to shared-state concurrency.

- It's IMO useless to ask people to learn Erlang or Scala to get message based concurrency. People use Java, C, C#, PHP, Python, and probably still COBOL somewhere. So the challenge is how to give this mainstream a toolset that lets them build large parallel applications.

Perhaps next year at FOSDEM we can do a devroom and take the time to see a real application evolve from a simple stand-alone process into a real distributed one. 0MQ is very hard to grasp as a theory, one needs to actually use it for a few days before the beauty a cheap, universal, fast, intelligent, easy to use, and asynchronous queuing messaging fabric hits home.

Cheers!

[nuxi]

I've glanced at the 0mq sources a bit, and I'm curious about the error handling. For example, zmq::tcp_socket_t::read() handles following errnos from recv(): EAGAIN, EWOULDBLOCK, EINTR, ECONNRESET and EPIPE. If recv() fails for any other reason (e.g. ENOBUFS, ETIMEDOUT) and returns -1, the following is performed:

  errno_assert (nbytes != -1);

which translates to

  #define errno_assert(x) \
    do {\
        if (unlikely (!(x))) {\
            perror (NULL);\
            fprintf (stderr, "%s (%s:%d)\n", #x, __FILE__, __LINE__);\
            abort ();\
        }\
    } while (false)

The first thing I noticed is the use of perror() and fprintf() for error reporting. Any daemon that closed its stdin/out/err and not had them redirected to /dev/null will most likely output errors to other file descriptors (sockets, other open files etc.). Is this by design or something that was missed?

Secondly, the use of abort() in an API is probably also not the best choice. Say I'm writing a (robust) database server and an error happens on one connection - the error will bring the whole server down, which kind of defeats the purpose. Is this also by design?

[Edit: formatting]