Nathan,
There is one issue we have to be careful about: pthread
_mutex_timedlock(): It needs the signal in order to wake up and return
from the wait. pthread_mutex_lock() just calls pthread_mutex_timedlock()
with and time value of NULL. So it is this NULL argument that is passed
must cause different behaviors: Non-NULL: interruptible and NULL:
noninterruptible.
Now, the subtle questions:
- Should the behavior of pthread_mutex_timelock() be the same as
pthread_mutex_lock() if the timeout is NULL? I don't see any discussion
of this at OpenGroup.org. My guess is yes.
- The timed wait will be awakened with a particular signal, but it could
also be awakened if an unrelated signal is received. Should there be a
signprocmask() to block other signals while waiting?
Greg
On 3/13/2020 4:34 PM, Nathan Hartman wrote:
On Fri, Mar 13, 2020 at 6:17 PM Gregory Nutt <spudan...@gmail.com> wrote:
If pthread_mutex_timedlock() would call pthread_mutex_take() with a
intr value of false, instead of true as it is doing now, that would
cause pthread_sem_take() to call nxsem_wait_uninterruptible().
But, I am *not* rushing to change this, because I don't know what else
it might affect (and also I'm not 100% sure that my reading of the
code is correct).
In the meantime, I'll continue studying it.
I am less concerned about what else might be affected (if you are
talking about applications) than about being in compliance with the
specifications.
In that case, there remains only the question of whether my reading of
the code is correct. I'll try to formulate a test.
Thanks,
Nathan
