Re: [Sbcl-devel] [SBCL-devel] Timed Condition Variable/Semaphore Waiting

[David L. R. <ra...@cs...>]

Hi,

Just a followup note below.

--David

>>> Another question concerns the return value of condition-wait when
>>> there was a timeout.  As of now, the lutex code returns 1.  This is
>>> slightly inconsistent with the current lutex behavior, where
>>> condition-wait always returns 0, if it returns a value at all.  Do we
>>> care?  It seems reasonable that the return value should be an
>>> unreliable indicator for whether a condition variable was signaled
>>> (for a reliable indicator, an object similar to CCL's
>>> semaphore-notification-object [search for "ccl
>>> make-semaphore-notification"] would be required).  It looks to me like
>>> waiting without a timeout on futexes and lutexes return different
>>> values anyway.
>>
>> I think as long as we are living with deadlines in addition to local
>> timeouts, the only right thing is to call (SIGNAL-DEADLINE) on
>> timeout, because you easily cannot tell if the timeout was due to the
>> local timeout or the global deadline.
>>
>> So code that _expects_ timeouts will look something like
>>
>>  (handler-case (condition-wait ... :timeout 0.1)
>>    (timeout () (whatever-we-want-to-do-in-case-of-timeout))
>
> I'm a bit confused as to what you mean by "local timeout" versus
> "global deadline?"  Does "global deadline" refer to functions similar
> to the sb-impl:with-deadline that I see in tests/deadline.impure.lisp?
>
> My personal preference is to avoid this handler-case and instead (1)
> use the return value as an estimate of whether the signal was received
> and (2) a notification-object to know for certain.  This
> notification-object should probably be added in a different patch.
> For all of my use cases, it doesn't matter whether the signal wasn't
> received due to timeout or for some other reason (like the thread
> being killed).  If the signal was received, I do one thing; otherwise
> I do another.  Anyway, I think your answer to my question in the
> previous paragraph will help address this concern.

I better understand this issue now (playing around with
"with-deadline" helped).

I'll think about it some more, but I'd ideally like to remove the need
to wrap the call to condition-wait with the handler.  That being said,
I have an interface built on top of condition-wait anyway, so I guess
it doesn't really matter whether _my_ interface has to include a
handler.  The with-deadline feature strikes my relatively
inexperienced brain as odd, but my patch should be consistent with it.