[Bug 209233] [patch] pthread_suspend_all_np races with check_suspend

[email protected]
Newsgroups gmane.os.freebsd.devel.threading
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209233

--- Comment #5 from Lawrence Esswood <[email protected]> ---
(In reply to Konstantin Belousov from comment #3)

I had a very wonky test that very unreliably failed, now I know why it happens
I can probably create a much better one to attach.

Your suggestion I think would work. You would also have to change the break
condition on the check_suspend loop otherwise if the thread is woken for any
reason it will break too early.

One question however, what happens if the thread in check_suspend has its
NEED_SUSPEND flag set and is signalled somewhere between the loop exit and the
_thr_signal_unblock? I think it won't do another check_suspend / check_deferred
until it next hits a _thr_ast which might be never. We could maybe extend the
thread lock to include the _thr_signal_unblock, or have the end of
check_suspend make a recursive call.

I will try knock up a test case.

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-threads
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.