All,
I’ve been contemplating for a while now, the idea of basically building a new
C11 version of nanomsg from the ground up. As I’ve spent more time in the
original libnanomsg code, I’ve become convinced this is absolutely necessary
for my own sanity.
I’m curious to better understand what things in libnanomsg people depend upon —
because some of the design goals that Martin originally laid out would be
difficult to achieve without the complexities in the code that are responsible
for some of my headaches. :-)
So, if you rely on any of the following, and would find the absence thereof
grievous, I’d like to know. (I.e. would the absence of these things make it
impossible for you to consider adopting a new implementation?) I’m especially
interested in hearing from folks responsible for maintaining ports of nanomsg
to different runtime environments (plugins via FFI calls and such.)
So:
1. File descriptor based interface? Is it important that you are able to mix
and match other kinds of file descriptors with nanomsg sockets?
- why problematic: file descriptors create challenges for transports
that might not be file descriptor based at all, such as inproc, or OpenSSL
(which uses a different handle structure), etc. Supporting plugin transports
is not going to be easy to do with this requirement.
2. Non-blocking I/O? Do you use NN_DONTWAIT in your application(s)? Would a
“blocking” API using threads work instead for your application? Also, do you
nn_poll()?
- why problematic: mixing non-blocking I/O with regular blocking
operations is pretty miserable, and the source of many bugs in libnanomsg and
in calling code. In my experience a blocking call, with a timeout if needed,
is better, although I concede that some runtimes — those without threads, are
going to be hampered by this. Also, to get these semantics, the library does
some fairly horrible things — a separate file is opened a single byte message
is sent as an alert to allow folks wanting access to poll & co to be seen.
3. Threads in general? Do you have a platform where threads (using C11 style
threading or some portable library using pthreads or Windows threads) won’t be
possible?
- why problematic - the only way to truly work around the absence of
threads is a crazy level of indirection and non-blocking I/O — frankly you wind
up with the umpteen zillion state machines that we already have, and which are
responsible for most of the current headaches in libnanomsg.
Basically, what I’m contemplating is a design that uses C11 style threads and
locking, along with an approach that is internally far closer to what I’ve done
in mangos (the Go implementation). I think that I’ll be able to achieve that
fairly in straight order. But I’m going to have to ditch some of the design
goals that Martin has set forth for libnanomsg. Ultimately I think that will
lead me to a more extensible, and more performant, and more robust,
implementation of the protocols. My experience with mangos gives me some
confidence in this regard.
Thanks.
- Garrett
