signals handling in the kernel

Mirek23 miroslaw.dach at
Thu Aug 23 20:57:00 EST 2007

Hi David,

    Thank you for your hints. I was not aware about race conditions in
signal handling routines. So far I did not noticed any anomalies when
running my server since I use only one interrupt which refers to only one
I would be interested however in the solution you have suggested with:
SIGIO and fasync() 

Would you be so kind to provide me with some example code.

Best Regards


David Hawkins-3 wrote:
> Hi Mirek,
>> In my case I found somehow more convenient to deal with
>> signals.
> Ok.
>> The server program which I use was originally written
>> for VxWorks. In VxWorks there was no separation betwenn
>> the user and kernel space. When the interrupt occured
>> in VxWorks the interrupt service routine was called.
>> The interrupt service routine was implemented in the server. 
>> I found it somehow easier to use signals to trigger signal handler
>> (previously in VxWorks interrupt service routine) than changing the
>> structure of the server to deal with select().
> I guess it depends on what you consider 'easier'.
> Signals have potential race conditions, and so using
> select() is safer. I find it 'easier' to have less
> problems, so would spend the time to make the server
> use select().
> But, you are free to ignore this advice. :)
>> I hope however that there is no fundamental problem with
>> sending signals from kernel (interrupt service routine)
>> to the user space.
> There are potential race conditions. I'm not sure if this
> problem was 2.4 kernel specific, or 2.6 kernel specific,
> or signals specific. I think its signals specific.
> A web search should yield more info on this. Try googling
> 'signals race condition', and it looks like its a problem
> still.
> So it depends on whether your server is running in
> a critical, and secure system, as to whether you want
> to stick with signals.
>> I do not know why the function kill_proc_info does not 
>> export its symbol within the kernel 2.6.21 .
>> With previous version of the kernel 2.4 and early 2.6.*
>> the kill_proc_info symbol was exported.
> If SIGIO is sufficient for you, then just use the driver
> fasync() call-back mechanism. The example code I referred
> to has an example. If its not clear to you, I can
> explain it.
> If you're having to modify some corner of the kernel not
> used by many, then I'm sure your solution is not the
> correct one, and you won't get anyone helping you
> when things go wrong.
> So, take the experience of others; re-write the server
> to use signals. If the server was well written to start
> with you should be able to call the 'signal handler'
> function after returning from your select() call with
> the handle ready. It shouldn't be that hard.
> Come on, you've just returned from holiday, it should
> be no sweat to code up a new server :)
> Regards,
> Dave
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at

View this message in context:
Sent from the linuxppc-embedded mailing list archive at

More information about the Linuxppc-embedded mailing list