In 11b8bbe one thing that was claimed was that we now properly set the
Notifier's actual fd on the NotifierActivationEvent. It turns out that
claim was false because a crucial step was forgotten: actually set the
m_notifier_fd when registering. Despite that mistake, it ultimately was
irrelevant as the methods on NotifierActivationEvent are currently
unused code. We were posting the event to the correct Notifier receiver
so the on_activation was still getting invoked.
Given they are unused, NotifierActivationEvent can be defined the same
way as TimerEvent is, where we just pass the event type enum to the
Event base class. Additionally, NotificationType can be moved to
the Notifier header as this enum is now always used in the context of
creating or using a Notifier instance.
The initial IOCP event loop implementation adjusted wake() to manually
queue a completion packet onto the current threads IOCP. This caused
us to now be dependent on the current threads IOCP, when the previous
behaviour did not depend on any data from the thread that was waking
the event loop.
Restoring that old behaviour allows https://hardwaretester.com/gamepad
to be loaded again.
The initial IOCP event loop implementation removed the single shot
timer fix added in 0005207 was removed.
Adding this back allowed simple web pages like https://ladybird.org/ to
be loaded again.
The initial IOCP event loop implementation had a fd() method for the
EventLoopNotifier packet that did not actually return the fd for the
notifier, but a to_fd() call on an object HANDLE that was always NULL.
This meant we were always posting NotifierActivationEvents with a fd of
0.
This rendered all of our WinSock2 I/O invalid, meaning no IPC messages
would ever be successfully sent or received.
The way these methods were previously defined, we would have to `move`
values into these functions. This was pretty awkward for plain types.
For example, doing a `move` here really doesn't make sense:
int resolution = 123;
promise->resolve(move(resolution));
Let's declare these methods in a manner that allows callers to choose
whether values are moved or copied, using perfect forwarding.
This macro outputs the time taken to reach the end of the current scope
to the debug console. It also shows the average time, total cumulative
time and the total number of calls.
It is also possible to limit the amount of debug output using
`REPORT_TIME_EVERY(name, n)` to only print every `n` calls.
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.
