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:
"After this call, the client session will no longer be valid. The 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 <[email protected]> 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 saving > 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 <[email protected]> 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_close. >> https://gist.github.com/22338464cd47e0e50970 >> >> >> So I guess my question is, is there any safe way to fork() while the >> 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?
