Thanks for your reply. But the problem still remains.
You described another scenario of alarm() usage -
> ... For instance, using alarm to
> unblock a blocking socket may give unexpected results:
>
> signal(SIGALRM, handler); /* Dummy handler */
> alarm(10); /* If the return from this call takes more than 10
> seconds, you lose */
> status = read(fd, buffer, len); /* You get stuck here forever */
But the solution is not failure proof.
> If you want to keep things simple, you could do something like:
>
> void handler(int sig)
> {
> global_variable= TRUE;
> }
>
> signal(SIGALRM, handler);
> global_variable = FALSE;
> alarm(timeout);
> if(global_variable == FALSE)
> status = read(fd, buffer, len);
> else
> ......
>
> alarm(0); /* Always cancel */
>
Suppose control was snatched away after the check
if (global_variable == FALSE)
and before the read() is called, and the alarm() went off between
these two ... This is possible because another process can get
scheduled in this duration.
The solution for this problem would be to use select() instead of
alarm().
Coming back to the original problem, I think someone in the standards
process can give an affirmative answer. I found that the problem
exists on other OSes too.
-- Sameer Shah, Ph. : +91-512-257653 (Lab.) Indian Institute of Technology E-mail : ocrds@iitk.ernet.in Kanpur 208 016, India