Wouldn't the absence of non-blocking I/O hurt projects like node-nanomsg?
On Sun, May 31, 2015 at 7:38 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
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
