Implement native timers #11294
Implement native timers #11294
Conversation
|
I am worried about whether this is the right interface. This is the only piece of I/O that we are conflating with channels. |
|
I agree that this may not be the right interface. There is one other place where we have I/O and channels: signals. Other than that though, this is about it. I've updated with comments. |
|
@alexcrichton @brson The proper interface would be to extend selection to select on both channels and OS objects (i.e. fds on Linux and handles on Windows). Then, the user just selects on the OS timer directly instead of selecting on a port fed by a timer helper thread that is selecting on the timers. This can be implemented by modifying port selection so it can tell the channel writer to perform the wakeup using an OS object (probably an eventfd on Linux, and an Event on Windows) instead of condition variables, and then use the OS object based mechanism for everything whenever there is at least one OS object being selected on. Same applies to signals: selection should be extended to select on signals too (with signalfd or perhaps by having the signal interrupt the system call). |
|
Can we just land this and improve the interface later? |
|
@bill-myers: using |
|
@thestinger Well, on Linux to wait on file descriptors you need to use epoll, select or poll on Linux, and these interfaces cannot wait on pthread condition variables (which are futexes), which can only be waited on using sys_futex, which only supports a single futex. Hence, to wait on both file descriptors and channels, one would need to use something else than a condition variable for the channel wakeups, which can be waited on using epoll. The most obvious option is to use an eventfd or pipe file descriptor for each task; it might be possible to use signals instead, although I'm not totally sure that it would be completely fine (e.g. can they be coalesced when using non-system signal numbers? will gdb breaking on those signals be too annoying?). I think the situation on Windows is similar. [I think the Linux kernel needs to be fixed to add ioctls on epoll fds to add futexes, if possible, but that's another matter and old kernels will need to be supported anyway even if one were to get a patch accepted to do this] |
|
ping r? |
This routine is currently only used to clean up the timer helper thread in the libnative implementation, but there are possibly other uses for this. The documentation is clear that the procedures are *not* run with any task context and hence have very little available to them. I also opted to disallow at_exit inside of at_exit and just abort the process at that point.
Native timers are a much hairier thing to deal with than green timers due to the interface that we would like to expose (both a blocking sleep() and a channel-based interface). I ended up implementing timers in three different ways for the various platforms that we supports. In all three of the implementations, there is a worker thread which does send()s on channels for timers. This worker thread is initialized once and then communicated to in a platform-specific manner, but there's always a shared channel available for sending messages to the worker thread. * Windows - I decided to use windows kernel timer objects via CreateWaitableTimer and SetWaitableTimer in order to provide sleeping capabilities. The worker thread blocks via WaitForMultipleObjects where one of the objects is an event that is used to wake up the helper thread (which then drains the incoming message channel for requests). * Linux/(Android?) - These have the ideal interface for implementing timers, timerfd_create. Each timer corresponds to a timerfd, and the helper thread uses epoll to wait for all active timers and then send() for the next one that wakes up. The tricky part in this implementation is updating a timerfd, but see the implementation for the fun details * OSX/FreeBSD - These obviously don't have the windows APIs, and sadly don't have the timerfd api available to them, so I have thrown together a solution which uses select() plus a timeout in order to ad-hoc-ly implement a timer solution for threads. The implementation is backed by a sorted array of timers which need to fire. As I said, this is an ad-hoc solution which is certainly not accurate timing-wise. I have done this implementation due to the lack of other primitives to provide an implementation, and I've done it the best that I could, but I'm sure that there's room for improvement. I'm pretty happy with how these implementations turned out. In theory we could drop the timerfd implementation and have linux use the select() + timeout implementation, but it's so inaccurate that I would much rather continue to use timerfd rather than my ad-hoc select() implementation. The only change that I would make to the API in general is to have a generic sleep() method on an IoFactory which doesn't require allocating a Timer object. For everything but windows it's super-cheap to request a blocking sleep for a set amount of time, and it's probably worth it to provide a sleep() which doesn't do something like allocate a file descriptor on linux.
Commit messages have the fun details Closes #10925
Commit messages have the fun details
Closes #10925