On Mon, Jul 6, 2020 at 7:14 AM Kenton Varda <ken...@cloudflare.com> wrote:
> On Mon, Jul 6, 2020 at 8:02 AM Vitali Lovich <vlov...@gmail.com> wrote: > >> On Sun, Jul 5, 2020 at 3:02 PM Kenton Varda <ken...@cloudflare.com> >> wrote: >> >>> On Sun, Jul 5, 2020 at 1:48 PM Vitali Lovich <vlov...@gmail.com> 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 capnproto+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CAF8PYMiq_JYSsF%3Djmi15%2BDspKHA2h3ig-tQh0YSMtVwW0rGgwQ%40mail.gmail.com.
