[nanomsg] Re: threading guidelines, and is traditional unix single threaded mode possible?

  • From: "Jason E. Aten" <j.e.aten@xxxxxxxxx>
  • To: nanomsg <nanomsg@xxxxxxxxxxxxx>
  • Date: Thu, 26 Sep 2013 21:54:03 -0700

On Thu, Sep 26, 2013 at 9:10 PM, Jason E. Aten <j.e.aten@xxxxxxxxx> wrote:

> A semaphore is necessary for cross-process unlocking, since mutexes are
> single-process only.  The parent would fork only once all parent threads
> were stopped on the semaphore. The lone child thread can then signal all
> other (N-1) parent threads to resume. Then the child would close the
> semaphore in its image.  Warning: I have not actually tried this, so there
> may be other pitfalls.
>

One important correction: the child doesn't signal to the parent; no,
instead, as
http://stackoverflow.com/questions/2620313/how-to-use-pthread-atfork-and-pthread-once-to-reinitialize-mutexes-in-childpoints
out:

"One potential workaround is to use POSIX semaphores in place of mutexes
> here. A semaphore does not have an owner, so if the parent process locks it
> (sem_wait), both the parent and child processes can unlock (sem_post)
> their respective copies without invoking any undefined behavior.
>
> "As a nice aside, sem_post is async-signal-safe and thus definitely legal
> for the child to use."
>
So it appears that the procedure is to have *both* the parent thread that
called fork, and the child thread after the fork, do a sem_post(), so they
both can proceed freely on their own copies of the semaphore.

It would wise at that point for the child to re-initialize nanomsg, so that
any behind-the-scenes nanomsg buffers are discarded and don't "leak" memory.

Note that all this presupposes that it is even possible to have all nanomsg
threads check and act on the global "prep-for-fork" flag regularly. That
may be impossible, I don't know.

Other related posts:

  1. Home
  2. nanomsg
  3. Archive
  4. 09-2013