[DTrace-devel] [PATCH v2 4/4] EINTR: respect switchrate in the core polling loop

[Eugene Loh]

On 11/2/23 09:42, Nick Alcock wrote:

> On 1 Nov 2023, Eugene Loh via DTrace-devel told this:
>
>> Again, I think MICROSEC is irrelevant;  NANOSEC/MILLISEC is more
>> meaningful (and it's what is done for converting from interval to
>> timeout_msec).
> I honestly don't understand why that would be more *readable*, given
> that you're talking about a denominator under a denominator here.
> I can change it if you insist...

There are no microsecs anywhere.  We want 1,000,000 -- not because we 
care about microsecs but because we want to convert between nanosecs and 
millisecs, which is why the existing code used NANOSEC/MILLISEC to convert.

>> Importantly, it seems like the test does not do anything.  My
>> impression is that the test is supposed to disrupt the loop, which
>> should nonetheless take the correct amount of time due to the patch.
>> I inserted some instrumentation into the loop to report if the body of
>> the while is ever encountered.  It is not.  I added some
> Really? I did the same thing and it was :)
>
>> instrumentation to report how long until the loop completes. It takes
>> almost no time (consistent with the body never being entered).  So I
>> think the test is passing simply because it's reporting the expected
>> time is being taken even though the new code never does anything.
> ... hm, maybe libdtrace is explicitly blocking a bunch of signals?
> That's not consistent with my observing this bug in the first place when
> I resized my window at the wrong time... but no, I see no sign that we
> modify the signal disposition of SIGWINCH at all.
>
> I think this may be your terminal environment or something. Signals with
> no handler are left unchanged across fork and exec, so if your
> controlling shell is ignoring SIGWINCH for some reason, DTrace will also
> end up ignoring it. Mine isn't doing any such thing. The Sig* entries in
> /proc/self/status before you start runtest might be informative...

Okay.  I don't know.

$ grep Sig /proc/self/status
SigQ:    0/30539
SigPnd:    0000000000000000
SigBlk:    0000000000000000
SigIgn:    0000000000000000
SigCgt:    0000000000000400