You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the IO API for the native platform in kona-common is inherently unsafe. Though, because it is behind the BasicKernelInterface trait, the API is not actually marked as unsafe lexically.
The reason the API is currently unsafe is because of our use of raw file descriptors. The FileDescriptor enum for the FPVM target is constant, and it is also Clone + Copy. However, on the native platform, file descriptors cannot be safely cloned or copied without checking for potential issues with creating a second handle to the fd.
This has resulted in a hacky workaround, where we hold onto the raw file descriptor, expect the host process to keep them alive for long enough, and construct + forget the file for read and write ops. While this works, the API is very unclear, and this invisible requirement of having the host keep the file descriptors alive is a bit annoying.
Instead, we should treat the FileDescriptor enum as an owned type. Cloning or copying it should be a falliable operation, i.e. OwnedFd::try_clone.
This will help improve the API to expose a truly safe native IO API, and prevent us from having to leak the Files in NativeIO.
The text was updated successfully, but these errors were encountered:
Overview
Right now, the IO API for the native platform in
kona-common
is inherently unsafe. Though, because it is behind theBasicKernelInterface
trait, the API is not actually marked asunsafe
lexically.The reason the API is currently unsafe is because of our use of raw file descriptors. The
FileDescriptor
enum for the FPVM target is constant, and it is alsoClone + Copy
. However, on the native platform, file descriptors cannot be safely cloned or copied without checking for potential issues with creating a second handle to the fd.This has resulted in a hacky workaround, where we hold onto the raw file descriptor, expect the host process to keep them alive for long enough, and construct + forget the file for read and write ops. While this works, the API is very unclear, and this invisible requirement of having the host keep the file descriptors alive is a bit annoying.
Instead, we should treat the
FileDescriptor
enum as an owned type. Cloning or copying it should be a falliable operation, i.e. OwnedFd::try_clone.This will help improve the API to expose a truly safe native IO API, and prevent us from having to leak the
File
s inNativeIO
.The text was updated successfully, but these errors were encountered: