Gnu c/c++: Alarm and read issue in linux

Gnu c/c++: Alarm and read issue in linux

[Mark Richards]

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

Re: Gnu c/c++: Alarm and read issue in linux

[Andres Heinloo]

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.