POSIX Asynchronous I/O

[jarun]

Currently nnn uses the cp and mv commands to copy and move files. Instead the POSIX Asynchronous I/O framework can be used to achieve the same.

For file attributes, functions like fchmod(), fchown(), futimens(), and setxattr() can be used after creating the new file to set its attributes to match the source file.

[jarun]

@KlzXS or @N-R-K ?

[N-R-K]

Wouldn't this be a huge amount of work? We'd need UI changes to show progress for when copying is ongoing and also some way to cancel the copy etc.

[jarun]

I think AIO would have the interfaces to query the progress, cancel etc.
We have to update the progress % somewhere in the two bars. Will check that part.

First I would like to see a basic file copy paste with attributes sample code snippet. We will work on the integration in nnn from there.

[jarun]

Note that we can also implement a keybind to see the overall progress in a different interface (like help).

[Hizenberg469]

Interested to contribute...

[jarun]

@Hizenberg469 initially please work on implementing a basic file copy paste using POSIX AIO along with the attributes.

If that goes fine, we will work on integrating it will nnn.

[Hizenberg469]

Ok, I will go through it...

[darukutsu]

So I tried something and what I don't get with aio is that does it really behave like queue and can I be certain that write will be processed after we read into buffer? Also what would be appropriate number of blocks or total size to queue before queuing another one, since files can be tremendously huge, we don't want to allocate bunch of blocks into memory. And since lets say we would need fork copy anyway because user while copying may decide to edit something or spawn process where nnn goes to sleep, thus blocking copy of next batch, why then not just use plain read/write forked.
I have somewhat working 2nd one with simple ui. With aio (1st one), I need to redesign it and I don't see value in it as of now. Even manpage suggests:

The current Linux POSIX AIO implementation is provided in user space by glibc. This has a
number of limitations, most notably that maintaining multiple threads to perform I/O opera‐
tions is expensive and scales poorly. Work has been in progress for some time on a kernel...

Would love to hear from @Hizenberg469 what he had come up with yet, I can't really find his changes anywhere. Asking this whether which approach should be continued.

What I tried before using: AIO 7c5e54f (first 2 commits really)
This fork solution: 87c21a2

Video how it looks for now (I put intentional small blocks and sleep so we can see how it works, since bar doesn't show if file copied fast):

asyncio-example.webm

Also wonder if I should do something with #2086 or this is task for external plugin rather.

[jarun]

Can we start each operation in a thread so that they don't get block by nnn flows?

[darukutsu]

I probably don't understand you, what you mean by flows? Everything is able to run in background while doing stuff like editing etc, since fork (except ui, will work on that).