[nanomsg] Aw: Re: testing help... shutdown race #1

  • From: "Peter Kuemmel" <syntheticpp@xxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Sat, 25 Apr 2015 12:43:05 +0200

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.

So you would say using state machines was a wrong design decision?
Wouldn't it help to refactor the state machine code?


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-----



Other related posts: