[KDE/Mac] [CODE] Multithreaded SIGSEGV signal handling, please examine

[Michael Pyne]

Hi,

I writing with a kind of sneak preview of a change I would like to make to 
KSharedDataCache (kdelibs/kdecore/util) in KDE 5.

The idea is to use a separate thread to perform the operations that actually 
access shared memory, since a good majority of KSharedDataCache bugs are 
reported as resolved by the user when they remove the cache file and allow it 
to be regenerated.

While it is best to ensure there's absolutely no logic errors in the cache, 
that's not the only source of cache corruption (BleachBit being run in a naïve 
mode of operation being the other popular source). With this change 
KSharedDataCache will be able to unlink the corrupted cache *and* prevent 
application crashes.

It utilizes several nuances of what I believe to be fully POSIX/SUSv3-
compliant code:

* The idea that SIG{SEGV,FPE,ILL,BUS} signals are directed to a specific 
thread (i.e. the thread that was running the code that invoked those signals).

* The idea that signal masks are per-thread (so that only the signals listed 
above would be delivered to the canary thread).

* Oh, and that sigsetjmp/siglongjmp actually work correctly. ;)

With that said I don't think the code uses as many POSIX options as the rest 
of KSharedDataCache (e.g. process-shared mutexes as unimplemented on Mac OS X) 
but I wanted to give a chance for you guys to test the prototype code 
beforehand and let me know if there's problems.

You'll want to compile with something like this:
$CXX -O2 -o sigcatcher -lrt -pthread sigcatcher.cpp

Make sure optimization is enabled to ensure volatile is used where it's 
needed. Assuming everything works right you should get output like:

$ ./sigcatcher
Hello, World!
Got a result of 1
Exited thread
$

If you want to see the signal handler in action there's a couple of lines you 
can uncomment (just grep for uncomment to find where).

Obviously any other feedback on possible issues is appreciated as well, but 
basically I'd like to catch any portability issues early this time instead of 
after-the-fact.

Please CC me on any replies as I'm not subscribed.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sigcatcher.cpp
Type: text/x-c++src
Size: 6816 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20110924/d45fe0a6/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20110924/d45fe0a6/attachment.sig>