Open milseman opened 3 years ago
Not sure if it's on the road map, but additional FileDescriptor
operations such as dup
and dup2
also support for the FILE
APIs? I'm not 100% sure if this aligns with this packages goals, just commenting because I was recently doing some things with these.
@allenhumphreys you're right, I'll add those. Sorry that I didn't see your reply earlier, I sometimes miss Github notifications (still trying to figure out why).
Thanks @miles. For reference, here's where I used the package. It's a great example of where the API's coverage is quite low.
Really glad to see this package coming along though!
Updated to reflect merged API that is yet-to-be-released, and added in references to Standard file descriptors, and Strongly-typed process and signal wrappers.
Just curious, does pipe
fit somewhere on this roadmap?
I had mentally lumped that under process types and calls, but it's not actually blocked on any design work there. We can add this anytime and might make a good starter task.
extension FileDescriptor {
static func openPipe() throws -> (read: FileDescriptor, write: FileDescriptor)
}
Pipes on Windows are somewhat interesting in that they behave differently. I think that it may be a good idea to ensure that we have a proper design to accommodate that properly.
@compnerd, would CreatePipe be an appropriate equivalent? It seems sensible to have an additional overload on Windows that takes a buffer size and perhaps security policy (or at least a Bool
for inheritability). Buffering has a default value and we can pick a default regarding inheritance for the parameter-less (or defaulted) API.
CreatePipe
can be used to create the anonymous pipe and that is better because you can control inheritability unlike with _pipe
. However, some things like like non-blocking IO on pipes isn't supported for anonymous pipes and changing the pipe buffer size is undocumented.
ftruncate
as FileDescriptor.resize
: https://github.com/apple/swift-system/pull/82
@milseman Would sendfile
(or maybe rather copy_file_range
) be a candidate that could make it to this package? If so, I'd be happy to create a PR.
@milseman Would
sendfile
(or maybe rathercopy_file_range
) be a candidate that could make it to this package? If so, I'd be happy to create a PR.
Yes, but I think that would be contingent on sockets, which got punted out (but hopefully we can readdress it soon)
This is meant to be a continuously-updated list of API candidates for System.
Criteria for Inclusion
System's primary aim is to be the place developers go to access native platform interfaces, presented in as Swifty a way as feasible. This positions System as a successor to Darwin/GlibC/SwiftWin32 and a “bedrock” upon which to enable better systems-level programming in Swift.
System is not aiming to be a cross-platform abstraction layer; there will be platform differences reflected in System's API. Of course, if a concept can be expressed the same way across platforms without harm or significant compromise to the developer's native experience on that platform, that's great. But, System's API should feel natural and native for the target platform.
System aims to provide API in 3 areas:
If a system interface exists, that’s strong justification for providing access to it in System as faithfully as we can.
System hosts common types for systems level programming, enabling libraries built on top of System to use the same, well-crafted types in their API.
For example, many API take locations in the file system, for which
FilePath
provides a common expression.System provides common utilities that users of System would otherwise find themselves having to reinvent. These usually have some combination of being pervasive, having obvious desired behavior, and being difficult/onerous to implement correctly.
For example, ensuring that a file descriptor is closed under all (non-pathological) conditions can be complex in the presence of error-handling, so System provides
FileDescriptor.closeAfter
.This area has a higher bar for contribution, requiring more justification and thought. What is "obvious desired behavior" and "correct" can differ amongst users of System.
Roadmap
Released
read
,write
,lseek
,pread
,pwrite
,open
,close
FilePath
,FileDescriptor
,Errno
,FilePermissions
closeAfter
,writeAll
FileDescriptor.standardInput
,FileDescriptor.standardOutput
,FileDescriptor.standardError
FileDescriptor.duplicate
, with optionalas
target.Merged
In Progress
ProcessID
,Signal
,SignalSet
,ProcessID.TaskInfo
,ProcessID.ResourceUsageInfo
posix_spawn
andexecv
functionality and interfacesSketches
Sketches are merge-worthy, quick-but-complete presentations of systems interfaces. They help to surface unknown-unknowns and can be easily adapted into a proposal. They are not necessarily named or expressed in their final form.
fcntl
sysconf
,pathconf
,fpathconf
openat
,fsync
,sync
Starter tasks
pipe
Near Term
Anything here could be added to System in the near term. Most of the functionality can be added by following existing API design patterns, though some will need new patterns.
usleep
)stat
,chown
, directory iteration, etc.pthread
low-level interfacesgetaddrinfo
,gethostent
, etc.~
expansion,currentWorkingDirectory
kqueue
/kevent
for Darwin,epoll
for Linux, APC (or something similar) for Windowsexit
,atexit
, etcioctl
, etcchmod
,umask
, etc.Long Term (vague "blue-sky" hopes)
File
typeProcess
typeio_uring
on Linux