[nanomsg] Re: bind is synchronous (mostly)

  • From: Bent Cardan <bent@xxxxxxxxxxxxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Thu, 2 Jun 2016 01:31:58 -0700

Woot woot!

Sent from my iPhone

On May 31, 2016, at 7:53 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:

As of today, I’ve committed a change to nanomsg which makes nn_bind() operate 
a little differently.  (Except for Windows IPC, but more on that in a minute.)

For all other platforms & transports, when you call nn_bind(), it will 
synchronously *bind*, and then arrange to do accept() asynchronously.

This means that if you have a port busy, it will return back EADDRINUSE for 
example.  Or if you give a port number that is bogus or illegal.  Its also a 
little more robust in that giving garbage in the URL won’t crash the library 
in nn_bind() with an assertion failure.  Instead you’ll get an error response 
back.

The accept() is still handled asynchronously behind the covers, so for most 
users the behavior won’t be noticeable.  The exception  would be if you 
somehow relied on it retrying bind() after failure.

The only scenarios I can think of for that are really edge case stuff, and 
should be done in application code instead.  (You can have a thread that 
retries nn_bind() until it succeeds if you need to.)  For pretty much all the 
usual cases the new semantic is actually more understandable, and preferable.

As a nice bonuses the state machinery got a lot simpler in the nn_bind() side 
of things, making the code smaller and easier to understand and debug.  It 
also makes the state transitions immediate, so it should not be necessary to 
ever insert a delay between nn_bind() and a subsequent nn_connect().

The one exceptional case is when using IPC on Windows (Named Pipes).  Because 
the Named Pipes API is so different, it does not return EADDRINUSE, and there 
is no initial check that the pipe can actually be created.  It turns out that 
Named Pipes on Windows have lots of other considerations (for example, did 
you know that you can’t have more than 255 clients connected to the same 
named pipe server — that’s an API limitation inside Windows).  I’ll probably 
fix this someday — but no promises here.  Windows IPC is definitely a second 
class citizen IMO.  (And it does work today, at least as well as it ever did. 
 Its just that you get no up-front checks.)

Anyway, enjoy, and feel free to give it a test from a fresh git pull.

We are almost ready for a 1.0 release candidate.

 - Garrett

Other related posts: