Comment 3 for bug 1760827

   Well, there are of course multiple ways to address this shortcoming. One approach compatible with the already published interface would optionally accept an timeout type (to be specified) argument instead of the timeout value. The former, as long as it isn't a trivial type, could then be modified within the CONDITION-WAIT function. Not exactly pretty, not easy to get the remaining-time value correct and not very FP-like, but possible (at least with approximate remaining-time).

   I'd argue however, that the problem is with the specification as much as with the implementation. In the manual [1] it is stated that these functions are "based on the POSIX condition variable design". Posix' pthread_cond_timedwait() however takes an "abstime" argument, which specifies the timeout as point-in-time (deadline), thereby bypassing the awkward remaining-time problem. I'd like to see that implemented. I'd dare to create a patch, if there's consens that this shall be the way forward and a change of published interface is deemed acceptable.

   Perhaps best might be to add a new function COND-TIMEDWAIT with a deadline argument and deprecate the timeout argument of COND-WAIT.