I recently started writing some SQLite user functions which may generate
SIGFPE. I’m a strong advocate of multi-threading—thank you Dr. Hipp, I
like running with scissors!—so in case my little functions ever get called
in multi-threaded code, I must needs enter the dark and dangerous world of
threadsafe signal handling.
My problem right now is that no matter what strange magic (or ugly
kludges) I work in my own functions, if any other code generates SIGFPE
elsewhere at the wrong time, the handler will walk straight into the wrong
stack snapshot. This, of course, will almost certainly crash the entire
process and very likely may corrupt data. I just don’t see a way around
this without platform-specific code.
My question hereby is, will the SQLite core itself ever trigger SIGFPE?
It seems it must be possible, in as much as SQLite regularly mashes up
user floats. To put it another way: Can the SQLite core *guarantee* that
it will never trigger SIGFPE? (Almost certainly no, but bears asking.)
SQLite question ends here. For those with a head for details, my current
plan is to do as follows in very exactly and precisely this order:
1.) Acquire global mutex (well, I did say “ugly kludge”)
2.) Set my signal handler for SIGFPE (which uses longjmp())
==> If any other thread which triggers SIGFPE here, whatever enters
the signal handler will fall into a stack full of arbitrary
garbage.
3.) if(setjmp(mystack)) { /*ERROR*/ } else { /*F.P. calcs*/ }
==> If any other thread which triggers SIGFPE here, whatever enters
the signal handler will will enter the stack for the current
thread. Oops!
4.) Restore previous SIGFPE handler
5.) Release global mutex
6.) Curse at <signal.h> for not being more thread-happy, and
hope that the C standards folks realize such a use case
should be fulfilled sometime before the next Ice Age.
(I have macros defined to do these things.)
P.S.—For those who might criticize my use of globals and the awful amount
of blocking it could create: I originally wanted to malloc() for separate
jmp_buf space and make separate mutexes for each connection to my user
functions. It seemed to make sense, since an sqlite3 object can only be
used by one thread at a time. Then I realized the obvious problem: I’m
dealing with a signal handler. Duh. Back to square one.
Very truly,
Samuel Adam ◊ <http://certifound.com/>
763 Montgomery Road ◊ Hillsborough, NJ 08844-1304 ◊ United States
Legal advice from a non-lawyer: “If you are sued, don’t do what the
Supreme Court of New Jersey, its agents, and its officers did.”
http://www.youtube.com/watch?v=iT2hEwBfU1g
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
