On Mon, Jul 6, 2020 at 10:22 AM Vitali Lovich <vlov...@gmail.com> wrote:
> 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. > I think there are a lot of use cases where you wouldn't want to destroy the AsyncIoStream object, though. For example, if I have a web server that's serving a file from disk, it might call getFd() so that it can use sendfile() to push bytes out without copying through userspace. But the stream can be reused for another HTTP request after that, so it can't be destroyed in the meantime. Hmm, in fact, for this use case it seems like the web server has to be able to get the FD *and* the UnixEventPort::FdObserver object together, so that it can use the latter to observe when the socket is writable. That's a bit of a problem since FdObserver is currently specific to UnixEventPort; when using something like the libuv compatibility layer in node-capnp, this wouldn't work. Maybe the answer is to define an FdObserver abstract interface. At least the way sockets work is pretty consistent across unix variants. (On Windows, of course, something entirely different is needed... but that was already true.) I don't like requiring an AsyncIoProvider to unwrap because it's generally uncommon to pass the AsyncIoProvider down into libraries. I think these kinds of optimizations should be possible to implement without requiring the library to take whole new, wide interfaces. -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/CAJouXQ%3DOU4FRRcn%2BzA9BQDBZ5FO-dcZiaKj8z1GAUdGsRueHzA%40mail.gmail.com.
