On Tue, Jan 3, 2017 at 1:52 PM, Michael Powell <mwpowellhtx@xxxxxxxxx> wrote:
I used mutex-guarded ryo message queues in a Linux environment and
they work well. Completely transparent to the caller; doesn't care how
it's guarded, just that it is thread safe. It seems to work well; just
have to be careful of message/payload move semantics to/from the
thread.
On Tue, Jan 3, 2017 at 1:50 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
Btw, as a consequence of this work, I have indeed identified some things in
mangos that can be improved. I’ve long had a plan to replace the use of
channels internally with message queues using mutexes and condvars, and I’m
convinced now that I can do this to get a nice performance boost.
I also think there are a few other areas where the code could just be
improved generally, to make it easier to extend, and clearer overall. I
hope to make some of those improvements, but right now I’m fairly focused on
getting this C version done.
Btw, my C version is passing its own internal tests thus far, using my
“Convey” framework, and is also passing valgrind cleanly. It has a few
different design goals from libnanomsg as well. It never panics / crashes,
even if out of memory, unless there is a clear a coding defect. There is
liberal use of error handling to deal with the various edge cases, and I
believe that once I reach the necessary functional capability, it will enter
life more ready for production use than libnanomsg is even now. (I’m
writing production quality code from day one, this isn’t just a design
experiment that will later try to evolve into production ready code.)
- Garrett
On Tue, Jan 3, 2017 at 10:45 AM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
Err… “mangos”.
On Tue, Jan 3, 2017 at 10:45 AM, Garrett D'Amore <garrett@xxxxxxxxxx>
wrote:
Why would I do that? I already have! It’s called “mango” Lol :-)
On Tue, Jan 3, 2017 at 10:42 AM, Jason E. Aten <j.e.aten@xxxxxxxxx>
wrote:
Cool. Garrett, do you plan on doing a Go version?
On Tue, Jan 3, 2017 at 12:22 PM, Garrett D'Amore <garrett@xxxxxxxxxx>
wrote:
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
