On Wed, Feb 03, 2021 at 09:43:01AM +0100, Martin Pieuchot wrote:
> On 02/02/21(Tue) 10:45, Claudio Jeker wrote:
> > On Mon, Feb 01, 2021 at 04:25:47PM +0100, Martin Pieuchot wrote:
> > > On 08/12/20(Tue) 10:06, Martin Pieuchot wrote:
> > > > Diff below aims to simplify the API to put a thread on a sleep queue and
> > > > reduce it to the following:
> > > > 
> > > >         sleep_setup();
> > > >         /* check condition or release lock */
> > > >         sleep_finish();
> > > > 
> > > > It is motivated by my work to sleep the SCHED_LOCK() but might as well
> > > > prevent/fix some bugs.
> > > > 
> > > > The tricky part of the current implementation is that 
> > > > sleep_setup_signal()
> > > > can already park/stop the current thread resulting in a context change.
> > > > Should any custom accounting / lock check happen before that?  At least
> > > > two lock primitives do so currently:  drm's schedule_timeout() and
> > > > rwlock's rw_enter().
> > > > 
> > > > As a result of this diff various states can be removed and 
> > > > sleep_finish()
> > > > contains the following magic:
> > > > 
> > > >         1. check for signal/parking
> > > >         2. context switch or remove from sleep queue
> > > >         3. check for signal/parking
> > > > 
> > > > Note that sleep_finish() could be simplified even further but I left
> > > > that for later to ease the review.
> > > 
> > > Updated diff on top of recent changes from claudio@, still ok?
> > 
> > Found the bug. The timeout for rwsleep() got lost. See below.
> 
> Thanks, updated diff addressing your points.
> 

OK claudio@

-- 
:wq Claudio

Reply via email to