On Mon, Feb 01, 2021 at 05:11:39PM +0100, 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? > > The sleep code makes my head spin but looking at this diff applied the > changes make sense and the order remains consistent. >
I may have spoken too fast. I see strange issues in firefox with this diff in. Need more time to better understand what is going on. For me firefox hangs on session restore (processes are stuck in poll). -- :wq Claudio
