Refactor Win32 iocp evloop#17101
Conversation
ysbaddaden
added
kind:bug
ysbaddaden
force-pushed
the
refactor/win32-iocp-evloop
branch
from
f32e0eb to
81fa6d3
Compare
|
There could be a better solution, maybe using queues and internal notifications to not go through IOCP again, for example a single global IOCP, lock-free singly-linked queues and |
ysbaddaden
force-pushed
the
refactor/win32-iocp-evloop
branch
from
81fa6d3 to
d07b73d
Compare
|
Rebased from |
We must assign every File and Socket to an IOCP instance for its whole lifetime, but we can start multiple event loops, each with its own IOCP instance, meaning that opening a file or socket in evloop A then reading and writing in evloop B would keep sending the events to evloop A. With execution contexts this isn't acceptable: 1. a context can shutdown (e.g. the isolated context) and evloop A disappear: the would no more valid evloop to receive IOCP notifications for the file or socket; 2. every evloop is expected to recieve events for its context only (not others) so we can enqueue locally; 3. if the threads running evloop A are busy they can block the fibers of evloop B.
ysbaddaden
force-pushed
the
refactor/win32-iocp-evloop
branch
from
d07b73d to
eb780d3
Compare
|
I forgot to fix the |
1 participant
Fixes BUG 1 and BUG 2 from #16675.
Creates a global IOCP instance, and associates every FILE and SOCKET handles to that global IOCP instance. Every OVERLAPPED operation is associated to the local IOCP instance.
Starts a thread that receives the completion events and forwards them to the local IOCP instance of the event loop that created the OVERLAPPED operation.
NOTE: this is required for the IOCP event loop to work with Execution Contexts.
Closes #16675 (BUG 3 can't be fixed.)