2009/3/25 Ken Thomases <k...@codeweavers.com>: > 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.
I'm not completely satisfied using signals (especially since they are not dynamically allocated and I may want to use more in the future) but signals was the lowest level alternative I could think about. This code will be used _very_ frequently and I want to use the lowest possible level, mainly for performance reasons but also for ease of setup. And signals seems like a reasonable alternative considering this. >> 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. I have only used GDB from within Xcode and it doesn't kill the process but according to the stack trace I get: 0 __kill 1 kill$UNIX2003 2 raise 3 SendCommandToService ... For a signal that I have told the signal handler to be ignored. The strange thing is that it works great as long as I don't invoke a breakpoint that starts GDB. So something about GDB makes the default signal handler being used despite having told it to be ignored. I can even put the line signal(SIGUSR2, SIG_IGN); just before the raise(SIGUSR2); line and it will still trap the signal – something it doesn't do if I run without GDB. It just makes it very hard to debug the code if I cannot use single step in GDB. > 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". When GDB stops it outputs: run [Switching to process 59985 local thread 0x2d03] Running… Program received signal: “SIGUSR2”. (gdb) ...but when I type something at the prompt it just ignores it – nothing happens when pressing return. / Påhl _______________________________________________ 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
