Limit execution time to 1ms

[Jaka Jančar]

Hi,

Is there any way to limit execution time to 1ms? Calling timer_create() and RequestTermination() from another thread is ok for double-digit timeouts, but not high resolution enough for single digit ones. Is there some callback on isolate thread that could be used for clock_gettime()?

Jaka

[Ben Noordhuis]

There's no such mechanism. I suppose you could blast the JS thread
with `isolate->RequestInterrupt(callback, data)` calls but that would
be very inefficient.

Since you're already using a watchdog thread, can't you nanosleep()
for approx. 997 usec and call `isolate->RequestTermination()`? If that
isn't precise enough, can you elaborate on why you need that kind of
resolution?

Aside: if you're using timer_create() with the SIGEV_SIGNAL flag, keep
in mind that `isolate->RequestTermination()` is _not_
async-signal-safe. SIGEV_THREAD or SIGEV_THREAD_ID is okay though.

[Jaka Jančar]

On the motivation: I have user-provided (synchronous, relatively simple) snippets of code that run 1k+ times/second on a server and must execute very predictably and fast or they can affect the rest of the system/users.

I'm using timer_create() with SIGEV_THREAD indeed (so not really managing my own thread). Perhaps SIGEV_THREAD_ID would be faster, because there is no scheduling/switching between two threads involved, but I was under the impression that functions need to be async-signal-safe for that as well, just as for SIGEV_SIGNAL. Can you explain why you think that is not the case?

[Ben Noordhuis]

On Tue, Jul 16, 2019 at 2:29 PM Jaka Jančar <ja...@kubje.org> wrote:
>
> On the motivation: I have user-provided (synchronous, relatively simple) snippets of code that run 1k+ times/second on a server and must execute very predictably and fast or they can affect the rest of the system/users.
>
> I'm using timer_create() with SIGEV_THREAD indeed (so not really managing my own thread). Perhaps SIGEV_THREAD_ID would be faster, because there is no scheduling/switching between two threads involved, but I was under the impression that functions need to be async-signal-safe for that as well, just as for SIGEV_SIGNAL. Can you explain why you think that is not the case?

With SIGEV_THREAD_ID you can just block the signal with
pthread_sigmask() and then wait race-free for delivery with
sigwaitinfo().

Having said that, unless there are other reasons to use timer_create()
or signals, it's probably easier to suspend with nanosleep() or
clock_nanosleep().

[Jaka Jančar]

Figured out my problem. I was using the CPU clock, and that has ~6ms granularity when used with the timer, I'm guessing it doesn't fire until the task is preempted and the CPU time tallied up.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to a topic in the Google Groups "v8-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-users/UcipYq1pJJE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAHQurc_7CwTdkvzTVCmHFP6xRa2%2B3E-xoftcbXCq6hbyz3GKvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.