Re: Immediate call_out takes 2ms
> 8.0.702 on macOS 10.14.6 : > > Pike bertrand$ for i in `seq 10`; do ./test_callout.pike; done > took 0.006 ms > took 0.007 ms > took 0.006 ms > took 0.006 ms > took 0.006 ms > took 0.006 ms > took 0.006 ms > took 0.005 ms > took 0.006 ms > took 0.006 ms The default backend in MacOS X uses kqueue(2) which uses a timespec for the timeout, and thus doesn't have the granularity issues that the affected poll(2) and epoll(2) et al have (which have a timeout granularity of ms).
Re: Immediate call_out takes 2ms
Hello, > In Pike 7.8 calling call_out takes 0.002 ms. In Ubuntu's Pike v8.0 > release 498 and in Opera's v8.0 release 610 it takes 2ms. Test program: […] > Is there a fix in younger version of Pike? 8.0.702 on macOS 10.14.6 : Pike bertrand$ for i in `seq 10`; do ./test_callout.pike; done took 0.006 ms took 0.007 ms took 0.006 ms took 0.006 ms took 0.006 ms took 0.006 ms took 0.006 ms took 0.005 ms took 0.006 ms took 0.006 ms -- Bertrand smime.p7s Description: S/MIME cryptographic signature
Immediate call_out takes 2ms
Fixed in Pike 8.0 and master.
Immediate call_out takes 2ms
>> Hi. >> In Pike 7.8 calling call_out takes 0.002 ms. In Ubuntu's Pike v8.0 >>release 498 and in Opera's v8.0 release 610 it takes 2ms. Test program: > >Seems to be a relative direct consequence of >7e8de5246b3012b055756293f2332494216646fd. /me scratches head. It seems there are two mostly unrelated changes in that commit: * Setting a minimum poll timeout of 2ms. * Disabling the paranoia clear of all revents. The commitmessage mentions a busy-loop for timing. I suspect that the problem that the code intends to fix is when there are call_outs that are pending in the interval 0ms < timeout < 1ms, where poll_timeout would get set to 0, but no call_out would be ready. The proper fix is probably to make the code round up instead of down: poll_timeout = (next_timeout->tv_sec * 1000) + (next_timeout->tv_usec + 999)/1000;
Immediate call_out takes 2ms
>Yes, that commit clearly sets the smallest amount of time to wait to >2ms. I wonder how fast the Bittorrent test would run without it? Should we revert this? A certain user I know for whom this might be important is certainly aware of it now and would be willing to patch that into their checkout of Pike if ... it turns out very beneficial for them...
Immediate call_out takes 2ms
Yes, that commit clearly sets the smallest amount of time to wait to 2ms. I wonder how fast the Bittorrent test would run without it?
Immediate call_out takes 2ms
> Hi. > In Pike 7.8 calling call_out takes 0.002 ms. In Ubuntu's Pike v8.0 >release 498 and in Opera's v8.0 release 610 it takes 2ms. Test program: Seems to be a relative direct consequence of 7e8de5246b3012b055756293f2332494216646fd. /me scratches head.
Immediate call_out takes 2ms
Hi.
In Pike 7.8 calling call_out takes 0.002 ms. In Ubuntu's Pike v8.0
release 498 and in Opera's v8.0 release 610 it takes 2ms. Test program:
int callouts_to_queue = 5;
System.Time t = System.Time();
int before;
void f()
{
exit(1, "this is not expected to run");
}
void start()
{
before = t->usec_full;
call_out(end, 0.0);
}
void end()
{
int delay = t->usec_full - before;
werror("took %f ms\n", delay / 1000.0);
exit(0);
}
int main()
{
for (int i = 0; i < callouts_to_queue; i++)
call_out(f, 3.0);
call_out(start, 0.0);
return -1;
}
Is there a fix in younger version of Pike?
Best Regards,
Tomasz Jamroszczak
