| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
During shutdown, waiting for callbacks might never complete, as queued
callbacks might not get executed under certain conditions. Not the clean fix,
but works good enough for now.
Seen on Windows in vici tests.
|
| |
|
|
|
|
|
|
|
| |
While we don't add FDs with an active callback to the watched FDSET, we still
can get notifications for callbacks active due the asynchronous processing
of the same.
To avoid queue multiple callbacks, we check for queued callbacks before
activating new ones.
|
| | |
|
| |
|
|
|
|
| |
This should make sure we refresh the fdset if a user closes an FD it just
removed. Some selects() seem to complain about the bad FD before signaling the
notification pipe.
|
| | |
|
| |
|
|
|
| |
Just queueing is problematic, as all threads might be busy waiting for events
that the queued (but never executed) job delivers.
|
| | |
|
| |
|
|
|
| |
Use non-blocking I/O on the read end of the notify pipe. This also makes sure
the read does not block should select() signal data while there is none.
|
| | |
|
| |
|
|
|
| |
This is important during shutdown, where we might need to signal some FDs while
all idle threads are gone already.
|
| | |
|
| |
|
|
|
|
|
| |
During daemon shutdown, users might call remove() after processor.set_threads(0)
has been called. This gets problematic, as a watch event might be unable
to signal completion when no threads are available anymore. Work around this
issue by cancelling waiters once processor.cancel() has been called.
|
| |
|
