Description
Specification
The monitor is necessary to enable re-entrancy within a call graph of certain operations like send
and recv
in QUICConnection
while also ensuring mutual exclusion between different call graphs.
However, the monitor
currently as used isn't using the monitor
resource acquisition function that I had earlier created in MatrixAI/js-contexts#2.
I just pushed out 1.2.0
of js-contexts
which exposes monitor
as a ResourceAcquire
.
You can remove the utils.withMonitor
in favour of doing something like this:
await withF(monitor(this.lockBox, RWLockWriter), async ([mon]) => {
await x.f({ monitor: mon });
});
Additionally in the beginning during QUICConnection.createQUICConnection
, you don't actually need to setup so much just to do the initial recv
and send
under after start
.
Also you don't need to lock anything in that scenario cause nothing is actually going to be able to intercept those calls during createQUICConnection
because nothing else has reference to the QUICConnection
instance.
I think it would far more clearer to write it in a way where your initial recv
and send
is just part of the async start
method. Just put your recv
and send
calls within that. It does not appear that start
is called anywhere else, so it can just be part of QUICConnection.start
.
Finally both send
and recv
should have mon?: Monitor
. Both should then use the withF
pattern above in case the monitor doesn't yet exist.
Additional context
Tasks
- Use
1.2.0
ofjs-contexts
to get access to themonitor
function. - Replace
utils.withMonitor
withmonitor
- Use
withF
pattern to create monitor for bothsend
andrecv
- Incorporate initial
recv
andsend
withinQUICConnection.start
, since that would be much clearer. You can still setup a monitor, but no locking is really required at that point. - In the
QUICServer
, why is there an additional separation ofconnectionProm
? This is unnecessary.