Re: takedescriptor and timeouts

Hi Scott,

<snip>
Strange idea. I wasn't aware that signals had different priority levels?!
</snip>

Yes, isn't it? There may or may not be any formal priority levels. By higher priority signals I'm referring to the fact that SIGKILL can't be blocked but SIGALRM can. The fact that a SysReq 2 could interrupt takedescriptor but SIGALRM couldn't informs us that the software, at least, performs differently depending upon the signal sent. This is expected, of course, as the signals ARE different after all. But the ability to block some but not others does suggest some form of blocking hierarchy.


<snip>
Are you certain that SIGTERM would interrupt takedescriptor()? It seems
odd to me that it'd block SIGALRM, but allow SIGTERM... but that's just
me theorizing, I've never tried it. But if I were writing the
takedescriptor() API, why would I only block SIGALRM?
</snip>

I would hope SIGTERM could interrupt anything. It is a termination request. I know the docs say SIGKILL can't be blocked. I'm assuming SIGTERM is the same. During my tests, whatever signal was sent via the SysReq 2 interrupted takedescriptor when SIGALRM didn't so some seem to get through where SIGALRM failed. Not sure what that signal was, but it gives me hope. :-)


<snip>
I suggest trying it (just send a SIGTERM from another job while it's
sitting on takedescriptor() as a test, and see if it reacts.)
</snip>

Will do. Would be interesting to see if alarm can send a SIGTERM. Even a SIGINT would be good for my purposes.


<snip>
In my last message to you, I suggested that you don't even call
takedescriptor() unless you _know_ that a descriptor is waiting to be
taken. (To do that, use a separate communication mechanism such as a
data queue to notify the program when it's time to receive a descriptor.)


You didn't respond to this idea.


</snip>

To be honest, if I had a free hand I would re-engineer the whole stack. But I don't. If the sending of a SIGINT / SIGTERM vial alarm doesn't work I'll suggest a redesign. At that point your idea of using Data Queues for the listening jobs to wait on would certainly come into play. But if rcvmsg can be interrupted I'd probably just move from the deprecated APIs to the newer ones.


<snip>
I can't find any documentation about whether takedescriptor() should or
shouldn't be interruptable. You say "should have been a case of..." as
if you know how it _should_ work? I haven't been able to find out one
way or the other... where did you see docs saying it should work?

</snip>

The doc does say this: If no descriptor is available to be received, the takedescriptor()
is blocked.

Which prompted me to be bold in my original message and state that takedescriptor is blocking SIGALRM.


Having said all that, I did say "should". But not because I know how it should work "as written in the technical document" (the docs say different) but by the fact that my experience tells me it "would be the appropriate and expected behaviour". I'd imagine this same sense of expected behaviour prompted the last line in your reply to my original post: "But... are you sure that alarm() doesn't interrupt takedescriptor?"

<snip>
At some point, an IBMer told me that givedescriptor/takedescriptor were
considered "deprecated" and although they'll still work for the
forseeable future, it was recommended not to use them. I can't recall
who it was, or what their complaint with these APIs was, but I remember
it was an IBMer, so it might be worth listening to. :)
</snip>

:-)

I agree, and it will certainly be my recommendation.

I will try sending a SIGTERM / SIGINT via alarm and see what happens. Will then move forward from there.

Thanks again.







Cheers

Larry Ducie