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

Nick Alcock nick.alcock at oracle.com
Mon Nov 6 11:43:31 UTC 2023


On 2 Nov 2023, Eugene Loh via DTrace-devel spake thusly:

> 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.

Ah. I wasn't reading it that way at all :) OK, that's clearer. (I
already adjusted things to work that way.)

>> 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

Doesn't look like anything is blocking it. Strange. I'll stop wasting
your time with this not-intended-to-go-in patch anyway :)

-- 
NULL && (void)



More information about the DTrace-devel mailing list