This commit changes the event loop to use IOCPs instead of
WaitForMultipleObjects to wait on events. This is done through the Nt
kernel api NtAssociateWaitCompletionPacket which associates an event
with a completion packet. Each completion packet notifies only once, as
they are normally used to signal completion of an operation so to use
them for notifiers they are associated again after each time they are
triggered.
There are more optimizations that can be done, such as reusing the
EventLoopNotifier and EventLoopTimer structures to reduce the number of
allocations and context switches for timer and notifier registration.
Our Core::System::is_socket() helper is not very robust, as it was
incorrectly marking m_fd as a non-socket fd. This meant we were trying
to call CLoseHandle() on a socket which fails. We can just call
closesocket() directly given we are in an explicit socket-only context.
When shutting down helper processes, PosixSocketHelper::close() in
SocketWindows when trying to close the socket fd with
WSANOTINITIALISED. This was due to us initiating WinSock2 during static
initialization and presumably also not terminating WinSock2 properly.
Similar to WinSock2 initiation, calling CRT during static
initialization is considered dangerous given the CRT DLL itself may not
yet be initialized.
Because of the above, we move to perform this Windows-specific
runtime setup/teardown calls into the main() functions.
This uses splice on Linux and mmap+write elsewhere to transfer a file to
a pipe. Note we cannot use sendfile because (at least on macOS) the
receiving fd must be a socket.
To detect system time zone changes on Windows, the event we need to look
for is WM_TIMECHANGE. The problem is how the callback with said message
actually gets invoked is very particular. (1) We must have an active
message pump (event loop) for the message to ever be processed. (2) We
must be a GUI application as WM_TIMECHANGE messages are seemingly sent
to top level windows only. It doesn't say that in the docs for the
event, but attempts of creating a LibTest-based application with a
message pump and a message only window and never receiving the event
point to that probably being true.
This workaround is built off the fact that Qt's message pump defined
internally in QEventDispatcherWin32::processEvents does in fact receive
WM_TIMECHANGE events, even though it is not exposed as a QEvent::Type.
Given the requirements stated above it makes sense that it works here as
the message pump is executing in a QGuiApplication context. So we use a
native event filter to hook into the unexposed WM_TIMECHANGE event and
forward it along to the on_time_zone_changed() callback.
Note that if a Windows GUI framework is done in the future, we'll have
to re-add support to ensure the TimeZoneWatcher still gets invoked.
Timers scheduled with identical `fire_time` could fire out of order
because the heap is not stable. This change assigns a monotonically
increasing `sequence_id` when a timer is scheduled and extend the heap
comparator to order by (`fire_time`, `sequence_id`). This guarantees
FIFO among timers with the same deadline.
This matches the HTML "run steps after a timeout" ordering requirement:
older invocations with <= delay complete before newer ones.
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout
There is no direct Win32 API equivalent, but calling WM_CLOSE on
the top-level windows allows for a graceful shutdown where resources
are able to clean themselves up properly
This first pass only applies to the following two cases:
- Public functions returning a view type into an object they own
- Public ctors storing a view type
This catches a grand total of one (1) issue, which is fixed in
the previous commit.
In SocketWindows, the return value for the ioctl call was not
initialized to zero. This was causing test_udp in TesDNSResolver
to fail as UDPSocket::read_some() was incorrectly failing with
WSAEMSGSIZE due the result of pending_bytes being some
unspecified default value for an uninitialized unsigned long
Both gdb and lldb interrupt execution after attaching to the process, so
no need to send a SIGTRAP immediately after which would require typing
`continue` in the debugger twice.
