On Mon, Jul 6, 2020 at 7:14 AM Kenton Varda <[email protected]> wrote:
> On Mon, Jul 6, 2020 at 8:02 AM Vitali Lovich <[email protected]> wrote: > >> On Sun, Jul 5, 2020 at 3:02 PM Kenton Varda <[email protected]> >> wrote: >> >>> On Sun, Jul 5, 2020 at 1:48 PM Vitali Lovich <[email protected]> wrote: >>> >>>> Yeah, so I'm still working through getting executeSync working. I do >>>> wish executeAsync would still be able to do the right thing when invoked >>>> from off-thread to avoid creating artificial synchronization points, but I >>>> can see it being challenging to accomplish something like that without >>>> adding synchronization into the happy path too. Basically the challenges >>>> I'm having is trouble terminating the event loop of a server. I *think* the >>>> answer I've stumbled upon is to wrap any futures I schedule with a >>>> cancellation object that I then cancel when I go to shut down the thread. >>>> I'm now seeing a crash on the non shutdown path though that I'm trying to >>>> figure out. >>>> >>> >>> Make sure you're using Executor::addRef() to take a strong reference >>> from the calling thread. Then if the receiving thread quits, the calling >>> thread should get a DISCONNECTED exception, but shouldn't crash. >>> >> Am I missing something? Executor doesn't inherit from refcount... >> > > It has a method `addRef()`: > https://github.com/capnproto/capnproto/blob/0050fd757683f140b4a07fdc3eab986db0d00c8d/c++/src/kj/async.h#L764 > > This was added fairly recently, though. Maybe it wasn't in 0.8.0. > Yeah that's why. I'll just update to the latest snapshot then. Yeah, that's what I figured. The KJ API is soooo much more user friendly >> though :). It would be cool to be able to consume the raw file >> descriptor/socket out of the pipes the LowlevelIoProvider constructs to >> simplify code/error handling. >> > > Yeah, I think adding `kj::Maybe<int> getFd();` (and `kj::Maybe<void*> > getHandle();` on Windows) to the `AsyncIoStream` interface is probably > something we should do. I resisted this for a long time since it breaks the > abstraction a bit, but there's just too many places where it would be > useful, especially for interoperability and optimizations. > And similarly transfer ownership out by having AsyncIoProvider have an unwrap methd that take in an Own<AsyncIoStream> and return an OwnFd? -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CAF8PYMiq_JYSsF%3Djmi15%2BDspKHA2h3ig-tQh0YSMtVwW0rGgwQ%40mail.gmail.com.
