On 1 June 2015 at 00:38, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
...
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.
Thanks.
- Garrett
