Ofer, Are you sharing one QueryParser among many threads? I instantiate and descruct a QueryParser within each thread and have never had any problems. Like your findings showed, never call os.fork() within your script or you'll be asking for trouble (which is why I'm guessing I was not able to use Flup in pre-fork mode and why you were not able to use that ActiveState recipe).
That's why you can use Daemontools to run your app; a fork system call is never made. TJ On Fri, 2007-03-23 at 15:47 -0700, Ofer Nave wrote: > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Andi Vajda > > Sent: Friday, March 23, 2007 1:30 PM > > > > On Fri, 23 Mar 2007, Ofer Nave wrote: > > > > > It > > <http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/278731> > > > works fine when run the Searcher a normal process, but when > > I run the > > > Searcher as a daemon, it freezes after about a dozen > > queries, in the > > > middle of the > > > queryparser.parse() call. It never gets past that point. > > I wrote a > > > SIGTERM handler for shutting down the daemon, and it works > > fine, until > > > the Searcher freezes, and then it no longer responds to the SIGTERM. > > > > > > Not sure where to go from here. > > > > You might want to ask [EMAIL PROTECTED] about daemonizing a > > process using libgcj and boehm-gc. > > I just did. Here are some of the replies from the list: > > --- > "It sounds like you're forking a gcj-compiled process, and then trying to > continue to run indefinitely in the child? > > If your _fork() call eventually translates to a Linux (or other Posix) > fork() call, that fundamentally won't work. Under Posix rules, only one of > the original threads survives in the child, and the child is thus extremely > restricted in what it can do: > > >From the SUSV3 fork man page: "Consequently, to avoid errors, the child > process may only execute async-signal-safe operations until such time as one > of the exec functions is called." > > This applies only to multithreaded processes. But Java (and gcj) processes > are always multithreaded." > --- > "If you want to daemonize, I would recommend doing it in C code before > calling JvRunMain. I am also unsure what happens if you close stdout and > stderr. I would hope that you don't do anything that would cause libgcj to > try to write to those descriptors. It might help to open stdout and stderr > to /dev/null" > --- > "You cannot call fork from within a libgcj based application and use it for > much of anything other than exec. > If you want to daemonize, you should do it before calling Jv_RunMain." > --- > > I don't understand most of that (my C is way rusty, and I've never been a > great system-level programmer). The second suggestion mentioned callin fork > before JvRunMain, which I'm guessing translates to forking before importing > PyLucene. I can try that. > > Still not sure what to do about QueryParser not being thread safe, other > than abandoning it. > > -ofer > > _______________________________________________ > pylucene-dev mailing list > [email protected] > http://lists.osafoundation.org/mailman/listinfo/pylucene-dev _______________________________________________ pylucene-dev mailing list [email protected] http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
