[nanomsg] Re: [Non-DoD Source] status update libnng

  • From: "Garrett D'Amore" <garrett@xxxxxxxxxx>
  • To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
  • Date: Tue, 3 Jan 2017 10:22:36 -0800

I’m about 24 hours from having TCP working.  Right now the TCP transport is
not written, though I’ve written a fair bit of it locally.

The REQ/REP pattern is working now, as is PAIR, and inproc is working quit
well and totally thread safe.

As far as lockless algorithms go — I’m a big believer in mutexes.  I need
mutexes and condition variables to make things work well, and in my
experience if they are used sensibly (with minimal contention), they do not
significantly impact performance.

For some things lockless data structures are superior, but you have to have
use cases that work for them; with mutexes and condvars I don’t have to
think about this; they Just Work.

It may be useful to look at alternative designs for that in the future, but
I’m only going to do that once I’ve demonstrated a clear need or benefit
(or maybe someone else will contribute at that point).  Until then, I need
to focus on getting the code working with a sensible design and avoid
prematurely optimizing things.

  - Garrett


On Tue, Jan 3, 2017 at 6:45 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) <
cem.f.karan.civ@xxxxxxxx> wrote:

-----Original Message-----
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx]
On Behalf Of Garrett D'Amore
Sent: Monday, December 26, 2016 2:46 AM
To: nanomsg@xxxxxxxxxxxxx
Subject: [Non-DoD Source] [nanomsg] status update libnng

Just a brief Christmas (western) update…

libnng is now managing connections.  There’s a lot more to this than
you’d think — and a lot of details that I’ve written under the hood.

 I expect that by New Years I’ll have it in a functional state for TCP
for POSIX systems, for at least the primary patterns / protocols.  TBH,
I’m really only a couple of hours from that point.

Note that the current code base is pretty much crash-immune with respect
to things that caused grief in libnanomsg — e.g. ENOMEM
errors will not impact libnng.  The whole approach has been from a
“correct first”, so I expect we will have fewer problems once we
actually start using this.

Things are moving apace… quite quickly actually.

If anyone is so inclined to review or give feedback on teh existing
code, I’m now at the point to receive it, understanding that there are
still large swathes still unimplemented.  You can’t use it for TCP for
example.  But at this point I’d rather solicit feedback early rather than
late.  Don’t tell me what’s missing, but if you see problems with what’s
already there, please *do* let me know.

I’m going on a ski trip for the next several days, but will probably
work in the evenings getting the thing to a state where other folks can
start playing with for actual experimentation.

I’m really looking forward to benchmarking this thing.  I think we’re
gonna blow the doors off libnanomsg, at least for platforms that have
non-crappy pthreads. :-)

Merry Christmas everyone! :-)

Thank you for all your hard work!

BTW, when you say that you can't use it for TCP, what exactly do you mean?

Thanks,
Cem Karan


Other related posts: