Re: takedescriptor and timeouts

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Hi Larry,

> I'm wondering if there is another timer-based signal raising
> mechanism that I could use to raise a higher priority signal.

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

> Or is it possible for alarm to raise a different signal to SIGALRM?
> A SIGTERM for example?

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?

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.)

> That would work for me. I want to end the job anyway, I just want to
> end it if takedescriptor doesn't return after a set period of time.

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.

> Cleaning the orphaned jobs after a set session timeout period should
> have been a case of setting an alarm when the job goes back on to the
> takedescriptor.

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?

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. :)