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
signal. 
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

Mirek




David Hawkins-3 wrote:

Hi Mirek,

quoted

In my case I found somehow more convenient to deal with
signals.

Ok.

quoted

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. :)

quoted

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.

quoted

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@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

-- 
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12291367
Sent from the linuxppc-embedded mailing list archive at Nabble.com.