On Mon, Aug 26, 2013 at 02:55:46PM +0200, Jerry Lundström
<[email protected]> wrote:
> Hi Marc,
>
> I'm using AnyEvent::DBI and was getting some strange behavior (corrupt SQLite
> databases after a select(?)) and noticed that the spawned process did not
> always exit correctly, it sill existed even after the AnyEvent::DBI object
> was gone. After trashing the module with a lot of debug output I saw that the
> TERM signal was most likely ignored in the serve_fh and resulted in the
> process still waiting for input after the object was gone. Checked the code
> where the TERM signal was sent and saw that it only closes the socket, no
> specific shutdown. Added shutdown (both read/write) and it seems to have
> solved this issue.
Hi, this is all very confusing. First of all, if SQlite corrupts it's
database that would be a bug in sqlite. Regarding signals, it's possible
that something sets it to ignore, but it looks as if, again, this would be
a bug in sqlite (it has no business messing with signals).
I could try to reset the signal handler, in case it was set to ignore or
so before forking, but sqlite shouldn't ignore it. I could also indeed ask
the server differently to exit, if possible
Lastly, closing unrelated fds again shouldn't affect sqlite, which would
be another bug in sqlite.
Overall, this is not very surprising to me - sqlite quality is truly
atrocious, and the internet is full of people who ran into corruption
or crash bugs even without AnyEvent::DBI (including me), so I guess the
primary way out here is to bring sqlite up to the standard of other
database interfaces.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
anyevent mailing list
[email protected]
http://lists.schmorp.de/mailman/listinfo/anyevent
