Asynchronous thread notification mechanism. #406
Conversation
| retFuture | ||
|
|
||
| when defined(windows): | ||
| proc wait*(signal: ThreadSignalPtr) {.async.} = |
There was a problem hiding this comment.
hm, what are the calling constraints here for fire and wait? ie which threads can they each be called from?
what happens for example if I wait from multiple threads?
There was a problem hiding this comment.
All the cases of calling wait() and fire() are now in tests. You can safely call wait() from multiple threads.
So if you have N threads called wait() on single ThreadSignalPtr instance, single call to fire() will awaken only 1 thread.
And you can call both wait and fire from same thread, you just need to avoid deadlock.
There was a problem hiding this comment.
So for any number callers to fire()/fireSync() from single or many threads and for any number of waiters via wait()/waitSync() for single or many thread, every call to fire()/fireSync() will wake up only one waiter via wait()/waitSync(), but ThreadSignal is not a semaphore so there could be only one pending fire() signal until waiter will not receive it.
| else: | ||
| cint(signal[].rfd) | ||
|
|
||
| if checkBusy(checkFd): |
There was a problem hiding this comment.
is it thread-safe to skip the writing here? if another thread reads just after this check, it might reset the conditions for the "writer" to fire again
There was a problem hiding this comment.
ThreadSignalPtr is supposed to wake only one waiter after one fire. To achieve this we should keep only one fire entity. Its pretty easy to make with eventfd on Linux and with Event on Windows, but sockets are not good at it, so we perform this check to avoid situation when we put 2 events into the sockets.
Fix the issue with multiple signals. Add tests.
Fix semaphoring issue on MacOS/BSD. Add tests.
No description provided.