is there a way to install an alternate signal
handler callback for_mainthread? i'd like it to
clean up upon SIGTERM etc., whereas it seems
that siginstall(SIGTERM)-ing etc. invariably
lead to _mainthread's OnSignal() callback just
exit()-ing. am i missing something? (as little as
i know about threads and signals, this isn't a
rhetorical question.) or do i just have to
sigaction() my own sa_handler that uses a differ-
ent callback when getThread()==&_mainthread?
posix version of library, Linux 2.4, glibc 2.2
thanks for any advice you can give. pointers to
remedial material on (Linux) thread and signal
interaction just as much appreciated
--buck
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Signal handling was not something I particularly wanted to introduce in Common C++ in the first place because it is not portable, even on the Posix side. Signal behavior varies, especially in regards to Linux, which treats each thread as a seperate process. In win32 I could find no equivilent facility at all for threaded signal handling.
That being said, yes, it is a limitation that there is no direct way to override the main thread with a derived class. One can just construct a global signal handler, and dispatch back into Common C++, as one solution.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
is there a way to install an alternate signal
handler callback for_mainthread? i'd like it to
clean up upon SIGTERM etc., whereas it seems
that siginstall(SIGTERM)-ing etc. invariably
lead to _mainthread's OnSignal() callback just
exit()-ing. am i missing something? (as little as
i know about threads and signals, this isn't a
rhetorical question.) or do i just have to
sigaction() my own sa_handler that uses a differ-
ent callback when getThread()==&_mainthread?
posix version of library, Linux 2.4, glibc 2.2
thanks for any advice you can give. pointers to
remedial material on (Linux) thread and signal
interaction just as much appreciated
--buck
Signal handling was not something I particularly wanted to introduce in Common C++ in the first place because it is not portable, even on the Posix side. Signal behavior varies, especially in regards to Linux, which treats each thread as a seperate process. In win32 I could find no equivilent facility at all for threaded signal handling.
That being said, yes, it is a limitation that there is no direct way to override the main thread with a derived class. One can just construct a global signal handler, and dispatch back into Common C++, as one solution.