-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
An idea for supporting cancellation in RandomAccess
on Unix
#96530
Comments
Tagging subscribers to this area: @dotnet/area-system-io Issue Detailscc @adamsitnik @stephentoub (?) I would very much like to switch to In my project, I implemented a type backed by a pipe + The idea is very simple:
I would assume the idea applies equally well to writes. The strategy is not entirely dissimilar from the one .NET already uses for async-over-sync cancellation on Windows. Has something like this already been considered? If not, would it make sense to adopt some variation of it?
|
This would be quite expensive, as it would create a new anonymous pipe for every file that we want to read from with cancellable tokens. Moreover,
@tmds would it be possible to implement something similar on Unix? For example by using signals? From what I can see Linux offers io_cancel sys-call, but it works only for AIO. |
I'm curious why you need
The if (!Console.IsInputRedirected)
{
Console.WriteLine("Input is a terminal.");
const int STDIN_FILENO = 0;
using var handle = new SafeSocketHandle(STDIN_FILENO, ownsHandle: false);
using var socket = new Socket(handle);
byte[] buffer = new byte[1024];
while (true)
{
int bytesRead = await socket.ReceiveAsync(buffer);
if (bytesRead == 0)
{
break;
}
Console.WriteLine($"Read {bytesRead} bytes.");
}
}
You could track the thread that makes the blocking call, and send it a signal to get EINTR. |
I do not think we need to create one for every file. For example, one strategy I can imagine here would be to create the pipe on demand when AFAIK anonymous pipes are not particularly expensive to keep around in terms of memory, and the buffer capacity can be adjusted down to the bare minimum with Seems not much harder than the Windows code I linked above, and the overhead should be minimal. I'd say it's well established that cancellation support (i.e. passing a cancellable token) always comes with some extra overhead to make the cancellation actually work.
It just so happens that My hope is to one day unify all my Windows/Unix terminal driver code around
I didn't know that; that is a bit neater. Do you think this would be cheaper than a pipe configured with |
Still curious about everyone's thoughts on the above; I would very much like to see Unix cancellation support here. |
cc @adamsitnik @stephentoub @tmds (?)
I would very much like to switch to
RandomAccess
in my terminal driver code. One hard blocker (aside from #58381) for doing so is that it does not currently support read cancellation on Unix. I know that #51985 is one way that could be solved, but frankly, that seems far off at the moment.In my project, I implemented a type backed by a pipe +
poll
to solve this. It's used like so when reading. (Obviously, it can be implemented much more efficiently, with fewer allocations and such, but as I only have two instances in an app, that wasn't a big concern for me.)The idea is very simple:
CancellationToken
is canceled, a byte is written into the anonymous pipe.poll(pipe, file)
.OperationCanceledException
.I would assume the idea applies equally well to writes.
The strategy is not entirely dissimilar from the one .NET already uses for async-over-sync cancellation on Windows.
Has something like this already been considered? If not, would it make sense to adopt some variation of it?
The text was updated successfully, but these errors were encountered: