On Mar 25, 2009, at 2:50 AM, Påhl Melin wrote:
I have a C++ singleton class where you call methods to execute commands that are actually performed by a background thread. When a command is "requested" it is put in a queue and I use raise(SIGUSR2) to wake-up the background thread. The reason I use signals to wake-up the background thread is that it communicates with other processed using Unix Domain Sockets and is listening to socket activity using a kqueue() and can also conveniently be used to listen to raised signals.
Have you considered using a pipe instead? Just send a single byte (contents unimportant) on the pipe to wake the thread. The thread should drain the pipe whenever it wakes up, and then check whatever state information necessary to do its work. Etc.
When the singleton is constructed the first time I use signal(SIGUSR2, SIG_IGN) to ignore the default signal handler to kill the process. And this works great when running the program both in Xcode and in a terminal window BUT when I put a breakpoint in the program and GDB is run, the program crashes when raise(SIGUSR2) is executed and kills the process as if the signal(SIGUSR2, SIG_IGN) had not been called (which I know has been called).
Are you sure the process is dying? By design, GDB stops (but doesn't kill) the process whenever it receives a signal. It allows you to investigate the state of the process if the signal was unexpected.
You can control this behavior using GDB's "handle" command. Try typing "help handle" or "info handle" at GDB's prompt.
You can deliver the signal to the process using GDB's "signal" command. You can also continue the process without delivering the signal using "continue".
Regards, Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
