250bpm

How do you plan on shutdown?

In ZeroMQ for example, I often setup different threads to handle various sockets. The threads will just listen for data and process it (think something like a worker thread). In ZeroMQ, we currently have a context.term(). This interrupts any threads or pollers to throw a ZMQException (in Java). I can then catch the exception and call socket.close() in each thread and close out the loops.

A possible solution is for the socket.close() to be thread-safe. I can then close the sockets from my main thread.

Two comments:

1)
Every API calls needs to provide a non-blocking variant
e.g. nn_close() always blocking will greatly complicate event-driven
code that assumes no blocking…

2)
To avoid locking between threads, are you planning to use
an implicit per-thread context (i.e. thread-local variable) in conjunction
with the shared/locked global state?

If the core of the library makes use of a context, then many options are possible:

1) Provide a shared implicit context for the entire process
+ the simple API you outlined above that uses the global context

2) An implicit per-thread context (totally independent or shared between some threads)

3) Multiple independent contexts under full programmer control

Contexts were a design mistake, yes. There are use cases for them but they should not be part of the basic API. However you don't need blocking as far as I can tell. What most apps do, and what the API should do, is maintain one context by default. A static thread safe object. Making this visible to the user and asking the user to take control was too complex (especially when we still asked the user to specify how many i/o threads to use…)

Still, with no contexts how do you shut-down the whole engine safely?

BTW the title of your post is misleading, you are not getting rid of ZeroMQ contexts. :)

Forking doesn't work well in 0mq. When fork()'ing, sockets are dup'ed, But the new (child) can't "close" them… because the context can't be reused. Then, if the parent tries to exit and reconnect, the dup'ed sockets block the bind() call.

After a fork, user should call nm_postfork(MODE)

Check to see if the pid associated with the socket is the same as the pid that opened it. if not, duplicated queues are cleared, and "file descriptor based" (tcp, unix) sockets are closed. All sockets are still valid in the child, but they are all "closed".

Especially when there are no "contexts" you need a way of handling fork()