iv_handle: Don't lose HANDLE active status when setting handler to NULL.

When the handler of an active iv_handle is set to NULL and then back
again to a non-NULL value, and the underlying HANDLE is of the auto
resetting variety, we would fail to invoke the newly installed handler
in the next poll cycle, and the active status of the underlying HANDLE
would effectively be lost.

Fix this by putting iv_handle objects that are active but currently
have no associated handler on a separate active list, and moving them
to the main active list when their handler is set to a non-NULL value.
(And skip calling WaitForSingleObjectEx() in iv_handle_poll_and_run()
if there are active HANDLEs when we enter the function.)

Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
iv_handle: Die if CreateEvent() fails.

Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
iv_handle: Maintain a per-thread list of all registered iv_handles.

Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
iv_handle: Remember to stop poll threads on iv_quit().

Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
iv_handle: Terminate poll threads via SetEvent() instead of via APCs.

iv_handle's rewait_handle becomes signal_handle, which will signal
not only that the iv_handle callback has been invoked and returned
and that the poll thread should resume polling the HANDLE, but also
that the poll thread should terminate (via the iv_handle ->polling
member).

Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
iv_handle: Remove unused 'numhandles' variable.

Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
iv_handle: Remove unnecessary initialization code from IV_HANDLE_INIT().

Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
iv_handle: Small signaling optimization.

If an iv_handle's handler callback has set its own handler to NULL,
there is no need to call SetEvent() on the iv_handle's signal handle
when the callback returns, as the poll thread will no longer be
running.

Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
iv_event: Fix list handling race condition.

In __iv_event_run_pending_events(), we move all items on the list of
pending iv_event items onto a local list head while holding the list
mutex, and then process the elements on the local list without
holding the list mutex.

This is unsafe, as the iv_list_del_init() calls that we do on local
list items as we process them and that are done without holding the
list mutex can race against the add-to-the-list-if-not-already-on-it
logic done in iv_event_post() (which _is_ done under the list mutex).

Fix this by keeping the list mutex held while we delete iv_event
items off the local list, so that iv_event_post() only ever sees the
iv_event item either still fully on the list or fully deleted.

Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
iv_event: Fix race condition in signaling via the fd poll method.

The kqueue and I/O completion port fd poll methods allow direct
signaling of iv_event activeness to remote threads (without having
to create a pair of pipes for each recipient thread).

However, the way this is currently done contains a race condition:
we would execute all pending event items (i.e. run user callbacks)
while we hold arrays of pointers to activated iv_fd objects, and if
one of those iv_fd objects is unregistered from any of the just
executed iv_event callbacks, we would end up with memory corruption.

Fix this by setting a flag if we get notification of there being
iv_event objects waiting for us to be processed, and only check
that flag and run the iv_event callbacks after we've processed all
pending activated iv_fd objects (by putting them on the active
list).

Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>