Re: takedescriptor and timeouts

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