On Mon, Jul 6, 2020 at 9:28 AM Vitali Lovich <vlov...@gmail.com> wrote:
> 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? > I think that could again be a method on the stream itself; doesn't need to be on AsyncIoProvider. OTOH, it might not be necessary to support ownership transfer. Instead, you could call getFd() and then dup() it (or DuplicateHandle() on windows). Then you can destroy the AsyncIoStream, which will close its copy of the handle, but you still have the duplicate. But if implementing a `Maybe<AutoCloseFd> releaseFd();` method seems easy then I'm fine with that. -Kenton -- 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/CAJouXQk5tM6XwVyyFED%2BV2fvxH%3Dw%2B-438wmLVG%3D%3DD%2BhcGEupvQ%40mail.gmail.com.
