> On Oct 5, 2020, at 1:35 PM, Mateusz Guzik wrote:
>
> On 10/5/20, Konstantin Belousov wrote:
>> On Sun, Oct 04, 2020 at 09:06:02PM +, Rick Macklem wrote:
>>> Mateusz Guzik wrote:
Why is the process lock always taken? It looks like both routines just
check a thread-local flag, so
On 10/5/20, Konstantin Belousov wrote:
> On Sun, Oct 04, 2020 at 09:06:02PM +, Rick Macklem wrote:
>> Mateusz Guzik wrote:
>> >Why is the process lock always taken? It looks like both routines just
>> >check a thread-local flag, so perhaps this can get away without
>> >serializing this process
On Sun, Oct 04, 2020 at 09:06:02PM +, Rick Macklem wrote:
> Mateusz Guzik wrote:
> >Why is the process lock always taken? It looks like both routines just
> >check a thread-local flag, so perhaps this can get away without
> >serializing this process-wide?
> I did spot this slight difference bet
Mateusz Guzik wrote:
>Why is the process lock always taken? It looks like both routines just
>check a thread-local flag, so perhaps this can get away without
>serializing this process-wide?
I did spot this slight difference between the initial version of sig_intr() and
this one. At least w.r.t. co
Why is the process lock always taken? It looks like both routines just
check a thread-local flag, so perhaps this can get away without
serializing this process-wide?
On 10/4/20, Konstantin Belousov wrote:
> Author: kib
> Date: Sun Oct 4 16:33:42 2020
> New Revision: 366429
> URL: https://svnweb.
Author: kib
Date: Sun Oct 4 16:33:42 2020
New Revision: 366429
URL: https://svnweb.freebsd.org/changeset/base/366429
Log:
Add sig_intr(9).
It gives the answer would the thread sleep according to current state
of signals and suspensions. Of course the answer is racy and allows
for fals