howard@ukpoit.co.uk (Howard the Hacker) (03/20/91)
I have a C program doing a msgrcv(2) which may be interrupted by a SIGALRM. This
is processed by a handler function. On return a failure of msgrcv is found
and found to be due to an interrupt. The question is, will any ignored signal
(ignored by default) also interrupt the msgrcv, and if so is it possible to find
out what the actual signal was? If the signal was not SIGALRM, the msgrcv should
not be tried again, but how can I tell?
The machine is an NCR Tower 400 running SVR2. The relevant code is:
while (amountReceived != scrnCtrlSize)
{
amountReceived = msgrcv(queueId,&scrnCtrlMessage,scrnCtrlSize, TO_CHILD,0);
if ((amountReceived == -1) && (errno == EINTR) )
/* a signal (probably alarm) was received and handled, so try again */
continue;
if (amountReceived != scrnCtrlSize)
/* something went wrong */
{
perror("<screenOp.c>:<156> message receive failed");
exit(1);
}
}
Thanks in advance,
Howard March
howard@ukpoit.co.uk
Sorry, no .signature, this is my first attempt to send anything.alan@ukpoit.co.uk (Alan Barclay) (03/20/91)
In article <1991Mar20.113657.1959@ukpoit.co.uk> howard@ukpoit.co.uk (Howard the Hacker) writes: > >I have a C program doing a msgrcv(2) which may be interrupted by a SIGALRM. This >is processed by a handler function. On return a failure of msgrcv is found >and found to be due to an interrupt. The question is, will any ignored signal >(ignored by default) also interrupt the msgrcv, and if so is it possible to find >out what the actual signal was? If the signal was not SIGALRM, the msgrcv should >not be tried again, but how can I tell? catch SIGALRM, using signal(2), set a flag in the signal catching routine, and check for the flag being set.
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (03/25/91)
In article <1991Mar20.114107.2078@ukpoit.co.uk>, alan@ukpoit.co.uk (Alan Barclay) writes: > In article <1991Mar20.113657.1959@ukpoit.co.uk> howard@ukpoit.co.uk (Howard the Hacker) writes: >> I have a C program doing a msgrcv(2) which may be interrupted by a >> SIGALRM. This is processed by a handler function. [...] [I]s it >> possible to find out what the actual signal was? If the signal was >> not SIGALRM, the msgrcv should not be tried again, but how can I >> tell? > catch SIGALRM, using signal(2), set a flag in the signal catching > routine, and check for the flag being set. That will tell only whether SIGALRM occurred, not whether some other signal also occurred. If a SIGHUP is delivered during the SIGALRM handler, for example, processing should stop, but the flag will be set just the same.... der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
guy@auspex.auspex.com (Guy Harris) (03/28/91)
>I have a C program doing a msgrcv(2) which may be interrupted by a SIGALRM. This >is processed by a handler function. On return a failure of msgrcv is found >and found to be due to an interrupt. The question is, will any ignored signal >(ignored by default) also interrupt the msgrcv, I assume by "ignored by default" you mean that the action for the signal is SIG_DFL, rather than SIG_IGN, but that the default action for the signal is to do nothing. If so, then an ignored signal will interrupt the "msgrcv()" only if you have a Mutant UNIX From Hell; the same applies to explicitly-ignored signals.
rbj@uunet.UU.NET (Root Boy Jim) (04/02/91)
In article <6853@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >If so, then an ignored signal will interrupt >the "msgrcv()" only if you have a Mutant UNIX From Hell Last night as I was walking home, several people started chasing me and yelling, "What's the signal, Kevin?". What does this mean? BTW, Happy New Year! -- [rbj@uunet 1] stty sane unknown mode: sane
bush@ecs.ox.ac.uk (Mark Bush) (04/02/91)
In article <127231@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: #In article <6853@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: #>If so, then an ignored signal will interrupt #>the "msgrcv()" only if you have a Mutant UNIX From Hell # #Last night as I was walking home, several people started chasing #me and yelling, "What's the signal, Kevin?". What does this mean? Possibly a bus error? 8*) #-- # [rbj@uunet 1] stty sane # unknown mode: sane Mark