Context: I'm experimenting ktls-core in Compio.
I noticed that, ffi::recv_tls_record() calls libc::recvmsg() directly, and ffi::send_tls_control_message() calls libc::sendmsg() directly. This would potentially block its callers (Context::handle_io_error()) if the socket doesn't have O_NONBLOCK in async environments, or bubble EAGAIN up to its caller on false I/O ready events. Particularly in completion-based async I/O systems like Compio, RecvMsg may be an operation that requires the runtime to explicitly submit to the OS, e.g. under io_uring, to avoid individual syscalls.
The question is like, are these libc::sendmsg()/recvmsg() syscalls going to stay in ktls-core as a reference implementation targeting blocking I/O environments? Or maybe you already have plans to fix this to be I/O-agnostic? Or perhaps, my understanding is all wrong and such syscalls just work fine for async systems?
Great abstraction btw, I like the neatness of the codebase!
Context: I'm experimenting
ktls-corein Compio.I noticed that,
ffi::recv_tls_record()callslibc::recvmsg()directly, andffi::send_tls_control_message()callslibc::sendmsg()directly. This would potentially block its callers (Context::handle_io_error()) if the socket doesn't haveO_NONBLOCKin async environments, or bubbleEAGAINup to its caller on false I/O ready events. Particularly in completion-based async I/O systems like Compio,RecvMsgmay be an operation that requires the runtime to explicitly submit to the OS, e.g. under io_uring, to avoid individual syscalls.The question is like, are these
libc::sendmsg()/recvmsg()syscalls going to stay inktls-coreas a reference implementation targeting blocking I/O environments? Or maybe you already have plans to fix this to be I/O-agnostic? Or perhaps, my understanding is all wrong and such syscalls just work fine for async systems?Great abstraction btw, I like the neatness of the codebase!