* Gnu c/c++: Alarm and read issue in linux
@ 2004-04-06 16:02 Mark Richards
2004-04-07 13:56 ` Andres Heinloo
0 siblings, 1 reply; 2+ messages in thread
From: Mark Richards @ 2004-04-06 16:02 UTC (permalink / raw)
To: gcc-help
Gnu c/c++: Alarm and read issue in linux
I'll start out by saying how enormously helpful this list has been to me.
As still very much a beginner with Gnu C and tacking an embedded project,
I'm stretched a bit, but enjoying every minute of it. I may also be doing
some stupids, so please call them as you see them.
I'm writing for an embedded system which uses the 2.2.5-15 linux kernel. The
code is being developed in RedHat 6.2 using egcs-2.91.66 (gnu c/c++).
Everything is working just fine - except for my implimentation of a certain
signal, called SIGALRM.
The signal system is, according to my understanding, the Linux way of
providing software interrupts. In the project I'm working on, a press of a
button (there are two in the embedded unit) is handled by a button device
driver.
The driver is initialized by:
int buttonFd = open ("/dev/button", O_RDWR);
Then the signal handler is setup:
volatile sig_atomic_t event_trigger = 1;
void catch_alarm (int sig)
{
cout << "Alarm event triggered" << endl;
event_trigger = 0;
signal (SIGALRM, int sig);
}
// this call sets up the connection between the alarm signal
// and the function catch_alarm
signal (SIGALRM, catch_alarm);
The code then enters a read() call which seems to hang (or block) the
signal. At the expected alarm timeout, nothing happens.
The following code below is in a second source file, so to connect back to
both the variable "event_trigger" and the function "catch_alarm", i am
declaring these:
extern volatile sig_atomic_t event_trigger;
extern void catch_alarm(int sig);
Here's the code that does the read():
alarm(10);
read (buttonFd, &c, 1);
I tried initializing the driver using:
int buttonFd = open ("/dev/button", O_RDWR | O_NONBLOCK);
but this had no effect.
Unfortunately I don't have the driver code, otherwise I think it might be
possible to set it up as a non-blocking driver.
My questions are:
1. Should alarm() work with a system call like read()?
2. If not, is there any work-around?
I've read a bit about waitpid() which seems like it might be an option, but
I don't have a good example as to how it could be used in this case.
Any and all suggestions will be eagerly heard.
Thank you!
Mark Richards
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Gnu c/c++: Alarm and read issue in linux
2004-04-06 16:02 Gnu c/c++: Alarm and read issue in linux Mark Richards
@ 2004-04-07 13:56 ` Andres Heinloo
0 siblings, 0 replies; 2+ messages in thread
From: Andres Heinloo @ 2004-04-07 13:56 UTC (permalink / raw)
To: Mark Richards; +Cc: gcc-help
Hi,
> My questions are:
>
> 1. Should alarm() work with a system call like read()?
Yes, the signal handler should execute. After that the call should either
continue or break with errno=EINTR (I don't remember what was the
behaviour of signal() on Linux---better use sigaction() in which case you
can control this behaviour).
However, it only works if the driver cooperates properly with the kernel.
> 2. If not, is there any work-around?
Non-blocking I/O, asynchronous I/O, select(), but, again, they must be
supported by the driver.
If nothing else works, you can read the device in a subprocess and send
the data to the main process via pipe (alarm() definitely works when you
read() a pipe) or use threads.
Andres.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-04-07 13:56 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-06 16:02 Gnu c/c++: Alarm and read issue in linux Mark Richards
2004-04-07 13:56 ` Andres Heinloo
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 read-only IMAP folder(s) and NNTP newsgroup(s).