Hello All,
I have recently found this library and I've been looking at the source code a
bit. I'm replying to this thread, because it hits on something that I have been
wondering about. I think I can sum up my observations thus far in a single
question. If you were to create a stand-alone implementation of just one
transport/protocol combination, completely ignoring the others, what would that
design/code look like? I'm asking this question, because there seems to be no
overlap between protocols (ie; you can't mix them together). I typically ask
myself this kind of question when I feel like complexity is getting the better
of me. I know this is an incredibly simple idea, but it has helped me in the
past. There have been occasions where I have actually implemented the code to
answer that question. I don't ever remember feeling like that exercise was a
waste of time. I hope this thread isn't the beginning of the end. That would be
very unfortunate.
Thanks,
-G
-----Original Message-----
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx] On
Behalf Of Peter Kuemmel
Sent: Saturday, April 25, 2015 5:43 AM
To: nanomsg@xxxxxxxxxxxxx
Subject: [nanomsg] Aw: Re: testing help... shutdown race #1
I *am* convinced, more than ever, that continuing to try to extend
nanomsg with new behaviors, is a losing battle. I understand I
think why Martin wandered off towards Mill.
Yep, the complexity is becoming unmanageable. It is still better than
the unstructured mess we've had in ZeroMQ though.
I've done some experimenting with mill but the complexity of the tool
(it's basically a proto-language) is too big for my taste.
As a result, I’m *strongly* disinclined towards efforts to continue
to extend libnanomsg itself. Instead, I am thinking the best
approach here is to consider libnanomsg a basic core, and to begin
work on a new more extensible, and sensible, library that is written
in C (and with Apache or MIT licensing) but which is more akin to
Mangos than libnanomsg. My gut instinct is that this will be a
vastly easier kind of product to extend and develop, although it may
come at some sacrifices to portability to embedded or other strange
environments.
Using getcontext/setcontext family of functions can possibly help.
With context manipulation functions the state machines turn into
farely trivial coroutines (the Go way). The implementation of
coroutines with getcontext/setcontext would be < 500 LoC and pretty
trivial to read and manage.
What we would give up (possibly) is portability. Looking at libtask
project, it seems that it can be made work on linux, BSD variants and
OSX. The other platforms are unclear. Looking at the Windows fibers
though reveals that there is almost 1:1 correspondence with UNIX
context manipulation functions.
I may wind up giving up on POSIX style APIs for that as well.
I would advise against it, but it's your call now. Still, the API can
be extended a la SCTP -- for example I wanted to have
nn_reqrep_send/recv functions to handle multiple parallel requests on
the fly or nn_pubsub_send/recv to handle topic manipulation.
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJVJMUOAAoJENTpVjxCNN9YH/8H/A3Btq2ez6HCy9jYfwqduSZO
f7Ir1at3tN0YGArlfaNs05S/wOc7bXITM20QI1u12HgCONSv2587g9CFPb+Fvfvd
PiSBmeqe8gMuT+blKCqxe4m6uB62izpyK2xxJv0Oe9J6k2DuW/l4HBif9N4Apf2u
KKxgVXgZPYDDspgLXBRdarj+sPdiepu5bHmDOfra3HIFxa/sKnAGdSWve5D4mT01
KtMD+JzHC295NqfX5beYzq14e2LQtSHtUawoiJpc4fY8Kz2U/K1Gm++/Xqg2cLFt
fYrbsqhp6So+lnlqqCINgCAUktzuwcMBmfl6cPSzgWStsfcg8a9g/gsKjJHibg4=
=Pya/
-----END PGP SIGNATURE-----
