@sustrik writes: One thing to consider would be using libuv
Garrett,
One thing to consider would be using libuv. It's C, well maintained,
portable between unix/windows and does most of the stuff that nanomsg aio
classes do now.
Martin
On 2015-06-01 09:51, Michael Powell wrote:
On Sun, May 31, 2015 at 6: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.
My professional opinion is that non-blocking is essential. Sometimes
in the form of a thread, definitely at the socket level (with or
without timeout), sometimes also with a callback. Speaking in terms of
C++0x/1y of course, neither here nor there for operational purposes.
Service-bus-isms, i.e. persisting messages until they can be sent, is
a wholely separate concern from the transport layer IMO; the API
shouldn't necessarily care whether that's to a file (or file system),
database, etc.
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've heard a couple of good talks on taming complexity; sometimes it's
necessary, only if it's necessary. But not simply for the sake of
having it.
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.
I haven't been following the Google / Go / mangos developments all
that closely, so not sure how much of what is hype, to tell you the
truth. But from the sounds of it, mangos may be gaining some traction
in these area(s)?
Generally, whenever I've approached messaging of any sort, I've
followed basic design principles of separation of concerns, separating
the application (i.e. messaging, framing, etc) and transport (i.e.
socket, blocking, etc). Mixing the two is usually a recipe for
needless complexity.
Thanks.
That's my two cents. HTH
- Garrett