The t_connect() could fail for various reasons, not only because of a timeout, for example TLOOK.  The Sun's 6564477 was touching this area and I believe there was some good reason for that.

I see.  But to solve that problem you don't really need all the fancy deadline-based timeout computation.

If we get a connect timeout, we're going to get one every time, so you can probably just give up in pass one if the error code says the connect timed out.

That would let you simplify or eliminate much of the code that's trying to keep track of "how much more time is left to wait?"

Or perhaps, only loop for things like TLOOK, but I suppose that would require more information about what what the error scenario there.

sorry: what what / what was...

Actually, on the timeout, t_connect() fails with t_errno == 9 (TLOOK), and t_look() returns 16 (T_DISCONNECT).  Is there some other way (other than the timeout) how the t_connect() could fail with TLOOK, and t_look() would return T_DISCONNECT?  I'm not sure, and the t_connect(3nsl) and t_look(3nsl) man pages does not give satisfying answer to resolve this question.  So we cannot exclude such possibility.  Because of that, there seems to be no reliable way how to be sure that t_connect() returned because of the timeout (other than to measure the time spent in the t_connect()).
Here is an example of a scenario:
The timeout is 10 seconds, so t_connect() is called with the 10 seconds timeout.  After 3 seconds, the t_connect() will return (fail) with TLOOK, so I'd like to handle this error condition and continue to wait in t_connect() for 7 seconds now.
I believe my proposed fix is going to handle the above scenario properly, but I'm not sure how it will work with your proposal.
Thank you.