It seems like what's needed here is a way to register a callback on
`kj::Canceler` which is invoked when cancel() is called. Then the
MembraneHook can register interest in being notified of cancellation,
wherein it can permanently disable itself.
Actually, there is a tricky way this can be done no
Hi Kenton,
I've been digging around the last couple days and the approach of adding
*MembranePolicy::getCanceler()
-> kj::Maybe* seems to be OK when it comes to getting rid of
outstanding requests from within the *MembraneRequestHook *and
*MembraneHook*, but I've run into some snags emulating
Hi Rowan,
Right, MembranePolicy today uses exclusiveJoin() to effect an asynchronous
revocation. The problem with such asynchronous revocation is that it
provides no explicit guarantee of when it's safe to assume revocation has
occurred. To use this safely, you probably need to detect when your
ob
Hi Kenton,
No stress, your time is given freely and I appreciate it.
Your suggestion makes sense to allow an immediate method of cancelling
outstanding requests wrapped inside a membrane. After a look over
*membrane.c++*, I do not see a *kj::Canceller* in use, so I presume this is
done using *
Hi Rowan,
Sorry for the slow reply, my inbox is overloaded as always.
Indeed, since the `onRevoked` mechanism is triggered by a promise, the
actual revocation and cancellation occurs asynchronously. It's possible
that some other promise will be queued in between the point where you
resolve the re
I've added an ugly unit test to a branch on my GitHub to illustrate:
https://github.com/capnproto/capnproto/compare/master...Zentren:capnproto:membrane_issue?expand=1#diff-49ad79a4fffcbe88fcd8681ec67d49f5f6e5fc9010961c1b10ef1b462f0e957eR477
Note line 477 in *c++/src/capnp/membrane-test.c++* where
