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

  • From: Nico Williams <nico@xxxxxxxxxxxxxxxx>
  • To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
  • Date: Thu, 26 Sep 2013 15:59:35 -0500

On Thu, Sep 26, 2013 at 3:13 PM, Jason E. Aten <j.e.aten@xxxxxxxxx> wrote:
> On Thu, Sep 26, 2013 at 12:56 PM, Nico Williams <nico@xxxxxxxxxxxxxxxx>
> wrote:
>>
>> One way or another you'd have to ensure that by the time the child-side
>> atfork handler runs the data structures are in a stable form, so it can
>> do whatever the right thing is.  Doing this does not come at zero cost.
>>
>> > regularly on a global integer flag (the "please-prepare-to-fork flag")?
>> > At
>> > most 2 poll intervals can elapse before every thread has noted the
>> > global
>> > flag and then prepared by taking locks or otherwise pausing. You'd only
>>
>> That would be one way of doing it.  Kernel-side locks would be involved,
>> so that that approach is not exactly lock-less :)
>
>
> Right, so not zero cost globally, but if you don't fork, you don't pay for
> kernel-side locks.  If you don't fork, you are
> only having to have every thread read a global integer (latch) regularly.
> Okay, epsilon cost, but negligible.
>
> I'm confused by your comment about locking being required, or perhaps my
> suggestion didn't land with you the way I described it. There would be no
> kernel side locks, no locks whatsoever, involved on the non-forking path.

Maybe I'm confused.  I think you're right that it should be possible
to have very low cost in the non-fork case, at the cost of slowing
down the fork case.  That might be a problem if, say, a subscriber
wants to spawn processes to act on incoming messages.

Note that a child-side fork handler could just set a global variable
to cause nanomsg to just fail safe on the child-side.  That should be
enough.

Nico
--

Other related posts:

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