Add blockio-uring dependency

[jorisdral]

Now that we depend on blockio-uring, we have to drop GHA for Windows and MacOS for now, until we have an alternative for those platforms EDIT: no longer the case, we are implementing an alternative API for Windows and MacOS

[dcoutts]

We could provide an emulation and use a conditional dependency. We'll need to keep things working on Windows and OSX, but without high perf support. So it seems better to keep the CI on those platforms continuously, rather than dropping and later trying to restore support.

[jorisdral]

We could provide an emulation and use a conditional dependency. We'll need to keep things working on Windows and OSX, but without high perf support. So it seems better to keep the CI on those platforms continuously, rather than dropping and later trying to restore support.

Okay, I'm marking the PR as draft again for now until I have this in place

[dcoutts]

Looking plausible.

Do we need to do separate posix and windows serial implementations? Can't we do a generic one in terms of the fs-api?

Another thing I'm wondering, perhaps the HasBlockIO API could have just the submit and close operations, and the initIOCtx could be moved to ioHasBlockIO. So the idea is that given an existing HasFS we can open a new block I/O context, and then use that. The advantage of this is that we'd have fewer things to pass around when using it. We'd just need to pass the HasFs and HasBlockIO and not also need to pass the ioctx.

I'm not sure how to make the params work generically. It's all very well to make it a type param and have a default, but if one wants to use a non-default value then it's not possible to write that generically. Hmm.

[jorisdral]

Looking plausible.

Do we need to do separate posix and windows serial implementations? Can't we do a generic one in terms of the fs-api?

We can have a single implementation, and I was planning on unifying the two this once I was sure everything was compiling on each of the OS's. And, fs-api doesn't provide buffer versions of reading/writing, so we can't implement it generically in terms of fs-api (yet). This PR includes the necessary preadBuf and pwriteBuf functions that I'll upstream to fs-api

Another thing I'm wondering, perhaps the HasBlockIO API could have just the submit and close operations, and the initIOCtx could be moved to ioHasBlockIO. So the idea is that given an existing HasFS we can open a new block I/O context, and then use that. The advantage of this is that we'd have fewer things to pass around when using it. We'd just need to pass the HasFs and HasBlockIO and not also need to pass the ioctx.

Sounds like a good idea!

I'm not sure how to make the params work generically. It's all very well to make it a type param and have a default, but if one wants to use a non-default value then it's not possible to write that generically. Hmm.

Maybe it's fine to just use the one from blockio-uring, and ignore it in the serial case

[dcoutts]

And, fs-api doesn't provide buffer versions of reading/writing, so we can't implement it generically in terms of fs-api (yet).

Ahh yes, good point. Yes upstreaming that makes sense. And indeed if we add that, it'll make some of our I/O conversion issues easier, e.g. where we want to read into a (Mutable)ByteArray directly.

Maybe it's fine to just use the one from blockio-uring, and ignore it in the serial case

Seems ok to me.

[jorisdral]

Okay, opened for review again. It's not completely final, but I'd like your input before I continue. In particular, I wonder if the serial implementation makes sense.

[dcoutts]

This looks great.

You asked about the serial impl. I think we can actually simplify that. See below.

Other than that I think this is good to go.

[dcoutts]

Ok, I think I see what is going on here.

So we're trying to implement the behaviour specified in the API:

Using 'submitIO' after 'close' should thrown an 'FsError' exception.

And we're doing that here by counting to track exactly when a IOCtx finally gets closed, so we can throw exceptions.

I think we can simplify. We're currently tracking this closing state, and then having submitIO fail if the ctx is closed by the time submitIO is finishing up. This is a bit odd. Firstly note that it involves submitIO and close being called concurrently. The API comments don't say what happens in this case, but in particular doesn't require that it cause a failure. Consider also what the blockio-uring one does: it make close prevent new submissions, and blocks until existing submissions have completed. So existing submissions are not made to fail.

We can simplify if we follow the latter behaviour: not requiring existing submissions fail, just failing new submissions after close.

In the serial case there's no actual cleanup that needs to happen since there are no extra resources. The only thing we want to do is catch incorrect uses of close vs submitIO. For that I think we only need an MVar Bool to distinguish the closed / not-closed state. We would check that on submitIO and set it in close.

[jorisdral]

And we're doing that here by counting to track exactly when a IOCtx finally gets closed, so we can throw exceptions.

New submitIO will throw an error on a Closing or Closed context. Existing ones don't throw an error, but we do record when all of them are done by switching from Closing to Closed.

I do agree we only need a Bool, and that the CtxState is keeping track of more info then we need

[dcoutts]

Changes LGTM.

[dcoutts]

Squash and merge!