From: David Hawkins <dwh@ovro.caltech.edu>
To: Mirek23 <miroslaw.dach@psi.ch>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: signals handling in the kernel
Date: Thu, 23 Aug 2007 09:32:55 -0700 [thread overview]
Message-ID: <46CDB6B7.4040907@ovro.caltech.edu> (raw)
In-Reply-To: <12291367.post@talk.nabble.com>
Hi Mirek,
> 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.
Look at simple_driver.c and simple_driver_test.c in
http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz
http://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html
Note that I used the old signals API in the user-space test:
/* Connect up the signal handler */
signal(SIGIO, &sigio_handler);
But you should really use the new signals API. I can't
remember the reason, it'll be explained in the Robbins&Robbins
book I reference below.
Note that another issue with signals is that they are
not queued. So if you have multiple events, you might
miss one.
I found a reference to unreliable signals. Take a look
at the signals chapter in "Advanced Programming in the Unix
Environment", by Stevens. However, that book is a bit old
now. The lack of safety may now only apply to that specific
signals API.
Another nice book is "Unix Systems Programming", by Robbins
and Robbins. Look in Chapter 8. Especially Section 8.6. That
section discusses the problems you'll face when your signal
interrupts POSIX calls, and functions that are signal handler
safe.
These types of issues would not be faced using select().
Hence the reason I can't remember the details on using
signals; as I rarely use them. The exception is that I
do catch ctrl-C to then shut down a process cleanly.
However, most of my user-space code is written using the
ACE C++ classes and infra-structure, and in that case you
deal with signals by creating an event handler, and
registering it with a reactor, which is implemented with,
you guessed it, select(). Notice the theme ... :)
The ACE C++ libraries are detailed in: "C++ Network
Programming" Volume 1 & 2 by Huston and Schmidt, and
in "The ACE programmers guide", by Huston et al.
Cheers,
Dave
prev parent reply other threads:[~2007-08-23 16:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-07 11:32 signals handling in the kernel Mirek23
2007-08-07 16:54 ` David Hawkins
2007-08-07 18:31 ` David Hawkins
2007-08-08 7:32 ` Mirek23
2007-08-08 17:19 ` David Hawkins
2007-08-30 15:23 ` Mirek23
2007-08-30 15:57 ` David Hawkins
2007-08-08 8:15 ` Mirek23
2007-08-09 13:47 ` Detlev Zundel
2007-08-20 11:49 ` Mirek23
2007-08-20 16:53 ` David Hawkins
2007-08-23 10:57 ` Mirek23
2007-08-23 16:32 ` David Hawkins [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46CDB6B7.4040907@ovro.caltech.edu \
--to=dwh@ovro.caltech.edu \
--cc=linuxppc-embedded@ozlabs.org \
--cc=miroslaw.dach@psi.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).