Rationale: Or why am I bothering to rewrite nanomsg?
nanomsg.github.io
Rationale: Or why am I bothering to rewrite nanomsg?
1–10 of 60 posts
Re: Rationale: Or why am I bothering to rewrite nanomsg?
#2I think you meant "Rationale"
Re: Rationale: Or why am I bothering to rewrite nanomsg?
#3Looks interesting, especially the Zerotier transport. Although I wonder why that's needed/what it means: with Zerotier you already have ip4/6 connectivity - what's the benefit of burying down below that?
Would that mean a "wireguard transport" would make sense as a default secure transport?
My other concern is that this starts to sound very big - have you been able to maintain clear modularisation of the code?
Re: Rationale: Or why am I bothering to rewrite nanomsg?
#4Looks interesting, especially the Zerotier transport. Although I wonder why that's needed/what it means: with Zerotier you already have ip4/6 connectivity - what's the benefit of burying down below that? Would that mean a "wireguard transport" would make sense as a default secure transport? My other concern is that this starts to sound very big - have you been able to maintain clear modularisation of the code?
>with Zerotier you already have ip4/6 connectivity - what's the benefit of burying down below that?
LibZT [1] provides a socket-like programming interface without requiring the full ZeroTier software and its system-wide virtual interfaces. I could see wanting to use something like nanomsg on top of that even though it's not an actual socket implementation.
Re: Rationale: Or why am I bothering to rewrite nanomsg?
#5> Sadly, this initial effort, while it worked, scaled incredibly poorly — even so-called "modern" operating systems like macOS 10.12 and Windows 8.1 simply melted or failed entirely when creating any non-trivial number of threads. (To me, creating 100 threads should be a no-brainer, especially if one limits the stack size appropriately. I’m used to be able to create thousands of threads without concern.
Both work just fine with hundreds of threads, and both offer built in thread pools, for that matter. I have 345 processes running on OS-X right now.
Re: Rationale: Or why am I bothering to rewrite nanomsg?
#6> Sadly, this initial effort, while it worked, scaled incredibly poorly — even so-called "modern" operating systems like macOS 10.12 and Windows 8.1 simply melted or failed entirely when creating any non-trivial number of threads. (To me, creating 100 threads should be a no-brainer, especially if one limits the stack size appropriately. I’m used to be able to create thousands of threads without concern. Both work jus…
I love when devs write their first non-trivial program in a language and all of a sudden their scaling problems are the OS fault and not their code.
Re: Rationale: Or why am I bothering to rewrite nanomsg?
#7I have to admit, after all these years, that I take everything coming from that general direction with a huge grain of salt. Crossroads I/O was supposed to be the great zmq successor and failed entirely, nanomsg was supposed to be an even better redesign of zmq and failed and now nanomsg-ng is supposed to be an even better design iteration on nanomsg.
Meanwhile the old/bad/bloated/poorly designed zmq just kept working fine all these years and even got a bunch of useful new features along the way.
Re: Rationale: Or why am I bothering to rewrite nanomsg?
#8> Sadly, this initial effort, while it worked, scaled incredibly poorly — even so-called "modern" operating systems like macOS 10.12 and Windows 8.1 simply melted or failed entirely when creating any non-trivial number of threads. (To me, creating 100 threads should be a no-brainer, especially if one limits the stack size appropriately. I’m used to be able to create thousands of threads without concern. Both work jus…
I think this is some kind of psychological projection/rationalization because the statement "Having been well and truly spoiled by illumos threading (and especially illumos kernel threads)" is actually quite laughable.
Re: Rationale: Or why am I bothering to rewrite nanomsg?
#9 > even so-called "modern" operating systems
> like macOS 10.12 and Windows 8.1 simply
> melted or failed entirely when creating
> any non-trivial number of threads. (To
> me, creating 100 threads should be a no-brainer
Re: Rationale: Or why am I bothering to rewrite nanomsg?
#10From the article:
> nanomsg has dozens of state machines, many of which feed into others, such that tracking flow through the state machines is incredibly painful.
> Worse, these state machines are designed to be run from a single worker thread.
Despite the negative tone, the author gives me the impression that nanomsg as a simple, consistent architecture that just needs to be documented better or perhaps refactored.
State machines are useful for precisely the reasons the author states: their behavior and performance are easy to reason about and state machines can enable concurrent processing of multiple tasks when when you're limited to a single execution thread.
The simplicity of state machines makes them useful for secure code or embedded processes where debug visibility can be poor. Embedded environments like microprocessors also benefit from the single-thread concurrency, but this can also be handy on more capable OSs if you want to cut the latency of fork() or pthread_create().
State machines are a really useful tool; there are worse complaints you could make about a code base.