Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (athena.apache.org: domain of slyphon@gmail.com designates
 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJe0eek2SqQ2ihQ40HyjS547KuugcGpoytB47oUHpgr1+qSqew@mail.gmail.com>
References: 
 <CAJe0eekuMKRmO_AMoox+JvZFb8P+dMdYW4PwOeJjzRgvrtfjuQ@mail.gmail.com>
	<CAHYqJpHg7jbyTwzpHUMGamtpRQa67M6aCzgrJ6ahr1WMEcysRw@mail.gmail.com>
	<CAJe0eem3z8w+zXQmZQ2P1Rjxi7BffvVWg2owcjvKFH5mG0BTUA@mail.gmail.com>
	<CAP1VaJvGzcympmOoUBr0yBxd7q+Vbd8wB__Aq8Y3iWHyDqBbtQ@mail.gmail.com>
	<CAP1VaJvwNv-Besu7VHLVAgykEjiPuASci7YXJUA_jEH+KC_QVQ@mail.gmail.com>
	<CAJe0eek2SqQ2ihQ40HyjS547KuugcGpoytB47oUHpgr1+qSqew@mail.gmail.com>
Date: Fri, 11 May 2012 00:19:28 -0400
Message-ID: 
 <CAJe0eenJB0jmjK5ZeRdSQ3mo+ZDddXg-L7gHab8oMSz4GZui0w@mail.gmail.com>
Subject: Re: How to deal with fork() properly when using the zkc mt lib
From: Jonathan Simms <slyphon@gmail.com>
To: user@zookeeper.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Well afaict SO_NOSIGPIPE doesn't exist in linux, which kinda sucks, as
I need this to be cross platform. I even tried hacking the source to
allow an option to not send the last message (diff is here:
http://is.gd/NptC0n and yes, I know this is an incredibly naive
attempt).

This would be an incredibly useful feature in my case (disconnect the
client and resume the session within the negotiated timeout).

BTW, is it possible to fork safely when using the st library?

Thanks

On Thu, May 10, 2012 at 9:46 PM, Jonathan Simms <slyphon@gmail.com> wrote:
> wow
>
> That's scary, but, probably also useful. :)
>
> I'm considering rewriting this using the st library, considering all
> the craziness necessary to use the mt lib.
>
> I'm gonna go try that out.
>
> On Thu, May 10, 2012 at 7:53 PM, Martin Kou <bitanarch@gmail.com> wrote:
>> If you don't mind the hackish-ness, I think you can just grab the file
>> descriptor from a Zookeeper handle like this for mt -
>>
>> int fd =3D ((int *)zhandle)[0];
>>
>> This works because the fd is the first field in the _zhandle struct.
>>
>> Best Regards,
>> Martin Kou
>>
>> On Thu, May 10, 2012 at 4:51 PM, Martin Kou <bitanarch@gmail.com> wrote:
>>
>>> I've had a similar problem as well, but I've been using the single
>>> threaded async library - I actually find it simpler to use than the mt
>>> library.
>>>
>>> The way I do it is this:
>>>
>>> During session connect -
>>> =C2=A01. Grab the file descriptor from the C library via zookeeper_inte=
rest()
>>> =C2=A02. If this is the first time I saw this file descriptor, and it's=
 valid,
>>> do a setsockopt() on it to set SO_NOSIGPIPE to 1.
>>>
>>> When I need to "suspend" the session
>>> =C2=A01. close() the file descriptor
>>> =C2=A02. call zookeeper_close() on the handle
>>>
>>> zookeeper_close() will try to send the close session message at step 2
>>> here. Normally, that would cause a SIGPIPE and your app would crash - b=
ut
>>> this time it won't because you've set SO_NOSIGPIPE on the socket. Inste=
ad,
>>> the Zookeeper library will see a regular error from its send operation =
and
>>> it'll free up the handle peacefully without closing the session.
>>>
>>> Best Regards,
>>> Martin Kou
>>>
>>>
>>> On Thu, May 10, 2012 at 4:11 PM, Jonathan Simms <slyphon@gmail.com> wro=
te:
>>>
>>>> Michi, fair point, I actually just looked into it, there doesn't seem
>>>> to be a way through the api to re-establish the session. If you call
>>>> zookeeper_close on the handle:
>>>>
>>>> =C2=A0"After this call, the client session will no longer be valid. Th=
e
>>>> function will flush any outstanding send requests before return. As a
>>>> result it may block."
>>>>
>>>> I tried:
>>>>
>>>> * establish session with handle A
>>>> * copy clientid_t from handle A
>>>> * zookeeper_close handle A
>>>> * construct handle B using clientid_t values from handle A
>>>>
>>>> I get back a SESSION_EXPIRED from the server. (debug from mt lib here:
>>>> https://gist.github.com/3b7e4060746d03cef287)
>>>>
>>>> It would be *really* useful if i could basically "suspend" a session
>>>> while i forked, then reconnect and pick up where i left off. Is this
>>>> not possible?
>>>>
>>>> On Thu, May 10, 2012 at 6:41 PM, Michi Mutsuzaki <michi@cs.stanford.ed=
u>
>>>> wrote:
>>>> > Hi Jonathan,
>>>> >
>>>> > It would be very difficult to share multi-threaded zk handle with
>>>> > child process. I'm surprised it actually works on mac. I think savin=
g
>>>> > session id/password and re-establishing the session in the child
>>>> > process is more robust and platform independent.
>>>> >
>>>> > Thanks!
>>>> > --Michi
>>>>
>>>>
>>>> >
>>>> > On Thu, May 10, 2012 at 12:45 PM, Jonathan Simms <slyphon@gmail.com>
>>>> wrote:
>>>> >> Hi all,
>>>> >>
>>>> >> I'm the maintainer of the ruby zookeeper library, and I'm having
>>>> >> trouble getting consistent behavior when a user calls fork(). When
>>>> >> developing it on MacOS (using 3.3.5), I was able to fork, then
>>>> >> immediately call zookeeper_close() in the child, and then create a =
new
>>>> >> handle. Testing on Linux, the behavior is much more unpredictable.
>>>> >> Regularly, it seems there are segfaults when calling zookeeper_clos=
e.
>>>> >> https://gist.github.com/22338464cd47e0e50970
>>>> >>
>>>> >>
>>>> >> So I guess my question is, is there any safe way to fork() while th=
e
>>>> >> client is running?
>>>> >>
>>>> >> Another possibility i thought of is to note the session id/passwd,
>>>> >> close the client, fork, then re-open with the same id/passwd to
>>>> >> re-establish the session in the parent.
>>>> >>
>>>> >> Any recommendations?
>>>>
>>>
>>>