Well, I've used it for a toy project, but never in production.
The good points are:
- write the code on UNIX and get Windows compatibility for free
- while it wouldn't get nanomsg rid of all the statemachines, it would
at least get us rid of the most problematic low-level ones
- the code & api look pretty decent
- AFAIU this project is a backend for node.js, rust et c. which means
it'll be maintained for a while
- the community is decent enough and responsive
Martin
On 2015-06-01 12:34, Jack Dunaway wrote:
@sustrik writes: One thing to consider would be using libuv
@sustrik -- what level of technical investigation have you done into libuv,
and based on that, how confident are you it would be a good path to take
for the core of libnanomsg? Any known immediate hurdles, or does it pass
smoke tests where the next phase is "just try it!"?
I have perused libuv docs and codebase a few times in the past, and I don't
have the chops or experience to formally recommend it for the future of
libnanomsg, but here are some things worth liking:
* libuv license is compatible with the spirit of libnanomsg
* battle-tested I/O abstraction enables libnanomsg developers to focus on
more relevant tasks than mastering the minutiae and errata of IOCP (mangos
is a successful case study!)
* there exists at least one project that integrates a TLS library on top of
libuv, where TLS represents perhaps one of the most significant and
desirable feature for libnanomsg, and this indicates it's also possible for
libnanomsg
* strategic advantage we might have if using libuv versus a C11 rewrite --
those of you with more exotic and/or limited targets could try to compile
libuv today and report back on findings. This flushes risk early.
* getting a bit off-topic, but additional features of libuv provide
interesting possibilities of other "concerns of a messaging library" that
we commonly reimplement at the application layer anyway
Briefly, knowing nothing more, libuv seems like a good idea as a basis for
a rewrite of nanomsg in C.
Kind regards,
Jack R. Dunaway | Wirebird Labs LLC
https://www.linkedin.com/in/jackdunaway
On Mon, Jun 1, 2015 at 1:24 PM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
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 C11style 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
