new FileStream(fd,..., isAsync:true) doesn't appear to be supported on Unix

[wasabii]

I don't appear to have any way to create a new FileStream from a raw int FD on Linux with async set to true. It's easy enough for me to call open() with O_ASYNC. The next step would be to create a SafeFileHandle, and then hand it to the ctor of FileStream. However, SafeFileHandle's Unix implementation seems to have no way to tell it the underlying FD is async. The Windows version calls into ntdll to actually detect whether the FD is async. The Unix version doesn't have any such call, and only sets IsAsync when it is responsible for calling open().

However, new FileStream(sfh,,,true) validates that IsAsync on the SafeFileHandle is true.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I don't appear to have any supported way to create a new FileStream from a raw int FD on Linux with async set to true. It's easy enough for me to call open() with O_ASYNC. The next step would be to create a SafeFileHandle, and then hand it to the ctor of FileStream. However, SafeFileHandle's Unix implementation seems to have no way to tell it the underlying FD is async. The Windows version calls into ntdll to actually detect whether the FD is async. The Unix version doesn't have any such call, and only sets IsAsync when it is responsible for calling open().

However, new FileStream(sfh,,,true) validates that IsAsync on the SafeFileHandle is true.

FileStream(IntPtr...true) seems to work, but is marked deprecated.

Author:	wasabii
Assignees:	-
Labels:	area-System.IO, untriaged
Milestone:	-

[Gnbrkm41]

It appears that you can query the flags set on a given file descriptor using fcntl function in F_GETFL mode, could we perhaps return the actual async-ness in the SafeFileHandle instead of storing whether the file descriptor was opened with one?

[adamsitnik]

Hi @wasabii

O_ASYNC does nothing for regular files on Linux. FileStream uses plain read and write sys-calls for pipes and sockets (no epoll), so there would be no gain from using it for these two file types as well.

From https://man7.org/linux/man-pages/man2/open.2.html

This feature is available only for terminals, pseudoterminals, sockets, and (since Linux 2.6) pipes and FIFOs.

If you are using sockets please use Socket type that provides full async support on Linux (via epoll).

In the future we might implement io_uring support for FileStream. Please follow #51985 for updates.

[wasabii]

@adamsitnik

At the OS level that might all be true, however, and I might be not completely accurate here anymore, because I'd have to fire up my tests again, it's been awhile.... I found that FileStream.ReadAsync/WriteAsync and similar methods were unusable unless FileStream thought it was talking to an async handle. They threw.

So, even though FileStream.ReadAsync would technically function on Unix by doing synchronous operations: it refused to do so unless it thought it was opened for async operations. And the only way to create a new FileStream that thought it was capable of doing so, from a FD, was to pass it a SafeFileHandle marked for isAsync.

Ignore O_ASYNC, as I suppose that was somewhat of a red herring for my purposes here. I need a FileStream that is capable of having ReadAsync called on it. And I need to initialize that FileStream from a FD. And there is no option to create a FileStream with isAsync: true, if the SafeFileHandle.IsAsync is false.

[adamsitnik]

FileStream.ReadAsync/WriteAsync and similar methods were unusable unless FileStream thought it was talking to an async handle. They threw.

These methods should always work no matter how you create the FileStream.

@wasabii Which .NET version are you using? Could you please provide a repro?