On Wed, Mar 18, 2020 at 1:31 PM Gregory Nutt wrote:
> There are some complexities and the possibility to break things. If you
> want, you could just create an issue with all of the relevant
> information and let it pend of awhile. I don't think there is any rush
> to change this behavior, is ther
On Wed, Mar 18, 2020 at 1:31 PM Gregory Nutt wrote:
> > To get the behavior POSIX specifies ("If a signal is delivered to a
> > thread waiting for a mutex, upon return from the signal handler the
> > thread resumes waiting for the mutex as if it was not interrupted.")
> > would require additional
To get the behavior POSIX specifies ("If a signal is delivered to a
thread waiting for a mutex, upon return from the signal handler the
thread resumes waiting for the mutex as if it was not interrupted.")
would require additional handling, such as (I'm guessing) checking the
cause of the wake-u
On Wed, Mar 18, 2020 at 10:11 AM Gregory Nutt wrote:
> >> 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
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
On Fri, Mar 13, 2020 at 6:53 PM Gregory Nutt wrote:
> 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
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
On Fri, Mar 13, 2020 at 6:17 PM Gregory Nutt 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
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 als
On Fri, Mar 13, 2020 at 6:12 PM Gregory Nutt wrote:
> On 3/13/2020 4:00 PM, Gregory Nutt wrote:
> > Sounds like it needs to call nxsig_wait_uninterruptible instead of
> > nxsig_wait somewhere in sched/pthread/
>
> s/nxsig_wait/nxsem_wait/g
>
> The calling sequence is:
>
> libs/libc/phthread:pt
On 3/13/2020 4:00 PM, Gregory Nutt wrote:
Sounds like it needs to call nxsig_wait_uninterruptible instead of
nxsig_wait somewhere in sched/pthread/
s/nxsig_wait/nxsem_wait/g
The calling sequence is:
libs/libc/phthread:pthread_mutex_lock() ->
sched/pthread:pthread_mutex_timed:pthread_m
Sounds like it needs to call nxsig_wait_uninterruptible instead of
nxsig_wait somewhere in sched/pthread/
On 3/13/2020 3:59 PM, Nathan Hartman wrote:
According to the description of pthread_mutex_lock() (in the
function's comment block):
"If a signal is delivered to a thread waiting for a mute
According to the description of pthread_mutex_lock() (in the
function's comment block):
"If a signal is delivered to a thread waiting for a mutex, upon return
from the signal handler the thread resumes waiting for the mutex as if
it was not interrupted."
But I don't see it. From my reading of the
13 matches
Mail list logo
