On Thu, Aug 24, 2006 at 08:55:03PM -0500, Matthew Nicholson wrote:
Nathaniel Smith wrote:
On Thu, Aug 24, 2006 at 06:49:37PM -0500, Matthew Nicholson wrote:
Did the new signal handling stuff (to fix the delay/freeze after ctrl-c
on mtn log) fix pidfile cleanup? The test seems to still be an xfail.
Umm, no... forgot about that :-).
It should be straightforward enough to come up with some hack to make
it work, though -- we have signal handlers, just need to teach them
when a pidfile exists, and to delete it, using some signal-safe code.
(The main thing to watch out for with such code would be "never
allocate memory". Calling unlink(2) should be fine, though.)
Hmmm... Right now it looks like the signal handler just prints a
message and exits.
Right.
pid_file tries to clean it self up when it is
destroyed. I don't like the idea of just sticking random stuff in the
signal handlers (didn't we just remove the journal clean up/db roll back?).
Right -- you can't stick random stuff in there, it doesn't work :-).
In particular, it's not possible to tell sqlite "do a rollback, but
_don't touch malloc while you're doing it_", which is what was causing
the crashes -- a signal would arrive while we were already inside a
call to malloc, which had locked the mutex protecting the heap, and
then the signal handler would call malloc, which would block waiting
for that mutex to become available...
However, removing a pidfile _can_ be done safely, if one is careful,
and the exercise does seem worthwhile. Just need some way for
pid_file and the signal handler to coordinate their actions.