POSIX timers

220 views
Skip to first unread message

Kalle Huttunen

unread,
Aug 27, 2020, 1:45:13 PM8/27/20
to emscripten-discuss
Does Emscripten support POSIX timers? My code using them compiles, but fails to link with undefined references to timer_create() and friends. I'm wondering am I missing some linker flag etc or are they just not supported.

-- 
Kalle

Sam Clegg

unread,
Aug 27, 2020, 3:26:32 PM8/27/20
to emscripte...@googlegroups.com
It looks like we do not support that today.  `timer_create.c` is excluded from the musl build in system_libs.py.

If you'd like to add it that would be most welcome.  It looks like you'd need to enable that `.c` file and then implement the time_create syscall in library_syscalls.js.

cheers,
sam

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/b6b76dd4-90ea-453a-ae4a-56355075d061n%40googlegroups.com.

Kalle Huttunen

unread,
Sep 1, 2020, 3:21:28 AM9/1/20
to emscripten-discuss
Ok, thanks for the answer. I started experimenting implementing the timers in my code with `emscripten_set_interval` and `emscripten_set_timeout` in the web build. Do you think this could be the approach also for implementing them in library_syscalls.js?

-- 
Kalle

Kalle Huttunen

unread,
Feb 9, 2021, 9:50:13 AM2/9/21
to emscripte...@googlegroups.com
Came back to this after a while, and it seems that using `emscripten_set_interval` and `emscripten_set_timeout` would not be a good option for a general solution after all, as they will try to invoke the callback in the calling thread, and there's no guarantees what the calling thread will be doing when the timer triggers. So it seems to me that some kind of timer specific thread would be needed.

-- 
Kalle

You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/RDb4CfuoSpA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/fa5a792f-b10c-4477-9572-8f8f3ab72c4en%40googlegroups.com.

Sam Clegg

unread,
Feb 9, 2021, 9:50:11 PM2/9/21
to emscripte...@googlegroups.com
On Tue, Feb 9, 2021 at 6:50 AM Kalle Huttunen <khu...@gmail.com> wrote:
Came back to this after a while, and it seems that using `emscripten_set_interval` and `emscripten_set_timeout` would not be a good option for a general solution after all, as they will try to invoke the callback in the calling thread, and there's no guarantees what the calling thread will be doing when the timer triggers. So it seems to me that some kind of timer specific thread would be needed.


JavaScript is single threaded, and handlers have to run to completion before another even can fire.  So when timers fire there is, by defintion, nothing else going on the calling thread.  The exception to this is ASYNCIFY which can make it appear that events occur mid-function.  If you are not using ASYNCIFY you don't need to worry about that.
 

Kalle Huttunen

unread,
Feb 10, 2021, 6:53:03 AM2/10/21
to emscripte...@googlegroups.com
What about worker threads? If `emscripten_set_timeout` is called in a thread other than main, the thread might be blocking somewhere when the timer triggers, no? It might also be that I'm misunderstanding some fundamental concept here... :)

-- 
Kalle

Sam Clegg

unread,
Feb 10, 2021, 1:05:15 PM2/10/21
to emscripte...@googlegroups.com
On Wed, Feb 10, 2021 at 3:53 AM Kalle Huttunen <khu...@gmail.com> wrote:
What about worker threads? If `emscripten_set_timeout` is called in a thread other than main, the thread might be blocking somewhere when the timer triggers, no? It might also be that I'm misunderstanding some fundamental concept here... :)


In that case the JS timer will never fire.   All events (including timers) require you to return to the event loop before they fire.  Actually blocking also blocks all events. 

Sarang Karandikar

unread,
Feb 11, 2021, 1:43:37 AM2/11/21
to emscripte...@googlegroups.com
Sorry to hijack this thread, I've a similar problem:

void TimerCallback(void* data)
{}
    emscripten_set_interval(&TimerCallBack20nullptr);
while (1)
{}
 
fails to call the callback in non-UI thread created with pthread_create() ( -s USE_PTHREADS=1 -s PROXY_TO_PTHREAD=1  )
Same code works correctly in the UI thread. I cannot block the UI thread obviously so doing the latter isn't useful and the former isn't working.

Any pointers would be highly appreciated.

Thanks,
Sarang.

Kalle Huttunen

unread,
Feb 12, 2021, 5:49:13 AM2/12/21
to emscripte...@googlegroups.com
Couple of different ideas come to mind for implementing timers in environment where you need to use them from worker threads that may block:

1. Implement a dedicated timer handling thread purely in your C/C++ code. The thread runs an event loop that receives the timer requests and wakes up to call the timer callbacks when timers expire.

2. Run the timers in the main thread using JS `setTimeout`/`setInterval`. You need to set up some kind of ID based callback system in C/C++ side, and call a C/C++ function from JS when the timer expires passing a callback ID as an argument. Something like this:

```
void callTimerCallback(int id)
{
    // look up callback based on id and call it
}

int mySetTimeout(MyCallbackType cb, int delayMillis)
{
    // register callback and get an id for it
    int id = registerCallback(cb);
    return MAIN_THREAD_EM_ASM_INT(
        "const cbId = $0;"
        "const delay = $1;"
        "const callback = () => { Module.ccall('callTimerCallback', 'void', ['number'], [cbId]); };"
        "return setTimeout(callback, delay);",
        id,
        delayMillis
    );
}
```

-- 
Kalle

Reply all
Reply to author
Forward
0 new messages