On Mon, Jul 6, 2020 at 8:13 AM Kenton Varda <[email protected]> wrote:

> On Mon, Jul 6, 2020 at 9:28 AM Vitali Lovich <[email protected]> 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.
>

I don't feel great about the duplication approach (or allowing retrieving
the raw handle directly) as it can be subtly tricky to actually use
correctly. For example, if you dup & make the dup'ed FD blocking, that will
impact correct behavior within cap'n'proto. So as a user you'd end up
wanting to always close the other FD after retrieving it. Since all usages
have you invalidating the stream & consuming the FD, putting it in the
provider is nice: it's symmetrical, you clearly have ownership of the
stream, and it's a natural spot to have flags to automatically make the
socket/FD blocking again.


> -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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/capnproto/CAF8PYMgEMcbqS3G4F%3Dw0ZRaAZ6-_v%2BUXwO9tHmuKWKydxi7d%3DQ%40mail.gmail.com.

Reply via email to