[nanomsg] Re: inquiry - nanomsg API
- From: Matthew Hall <mhall@xxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Mon, 1 Jun 2015 18:22:24 -0700
On Sun, May 31, 2015 at 03:38:39PM -0700, Garrett D'Amore wrote:
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.
I could live with it if there were something like nn_fileno(), to allow one to
construct a polling loop, for transports where a working FD is available.
Perhaps with another call nn_fdflags)_, which says what operations the
descriptor needs checked right now (I think SSL calls that WANT_READ and
WANT_WRITE), then you have to pass the descriptor back to nanomsg to let it
get a crack at the descriptor to do the I/O. If some particular FD didn't
support a given transport, then an error could be returned, and it's up to the
caller if they want to give up their polling loop to adopt a new transport.
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.
I do use the NN_DONTWAIT on the TX side... I have security sensors that are
constantly gathering events using the Intel DPDK user-space polling-mode
network stack, and any delays would cause packet loss or disruption of the
DPDK side of the app, which uses nanomsg to pass up the messages to an
analytics system. The way I handle it is to rely on nanomsg to keep the pipe
open and reconnect as best it can, and deliberately drop anything when the
queue buffer is full or the TX side is broken and won't take more data right
now.
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.
I don't really care if it does C11, pthread, OpenMP, $SECRET_SAUCE, etc. under
the hood, as long as whatever it does won't break any of the app's own
threading. I selected it for the extremely simple and logical C API and other
language bindings, and the fact that it deals with all the messaging and
transports and scalability protocols on my behalf without adding much
complexity or weirdness in the process.
Matthew.
Other related posts:
