Re: takedescriptor and timeouts

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Do you have the sigaction() set up properly?   i.e. if you replaced 
takedescriptor() with sleep() (just for the sake of a test, mind you) 
would it successfully receive the alarm() signal?   (Just to rule out a 
bug in your sigaction code...)

Assuming that the problem really is in takedescriptor() instead of 
something with your signal mask or signal configuration, then would you 
be open to alternatives?

For example, back in the V3 and V4 days when I still used 
takedescriptor(), I would always have my workers sitting on a data 
queue.  I wouldn't call takedescriptor() until the data queue had an 
entry -- therefore the program would never block on takedescriptor(), 
because I would only call it when I knew there was a descriptor to take.

Alternately, you could eliminate takedescriptor (I know I haven't used 
it in 10 years) and use sendmsg() and recvmsg() instead.  I'm confident 
that _they_ will be interrupted by a signal.

Or... depending on what you're doing... you might find spawn() to be a 
better choice.  It handles the submit and the descriptor passing all in 
one fell swoop.

But... are you sure that alarm() doesn't interrupt takedescriptor?


On 10/8/2010 12:30 AM, Larry Ducie wrote:
> Hi all,
>
> We have some code that listens on a takedescriptor and want to put a timeout on it. If the timeout is reached then we'll can the job.
>
> I tried:
>
> alarm(seconds);
>
> sd = takedescriptor(*null);
>
> alarm(0);
>
> But takedescriptor blocks!
>
> The handler procedure set for alarm isn't called when the time runs out. Once the timeout has occurred nothing happens. If I pass a descriptor after this timeout period takedescriptor completes and the handler procedure is THEN called. So SIGALRM is being blocked by takedescriptor until it completes.
>
> Any of you guys/gals have an alternative solution? I know other signals can not be blocked but I need a timer-based solution so a call to kill wont do it. Also, I can't replace takedescriptor with rcvmsg because other processes are using givedescriptor, not sndmsg.
>
> Any and all help is welcome.
>
> Cheers
>
> Larry Ducie
>
>
>