[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