fail to run Q1 in async mode.

[xx789633]

Hi, this is a really great work!

I followed the readme and can successfully build this project. But the code fails in https://github.com/L-v-M/async/blob/main/storage/src/storage/file.cc#L63 when I run query 1 in async mode. The bytes_read returned is -22.

I have checked the code in IOUringAwaiter. It's weird that the SetResult would set _result to be 0, but await_resume still returns result_ with value -22.

I'm not really sure whether this is a bug or it comes from a wrong system configuration. I did the experiment on a fresh ubuntu 20.04 with gcc-11.1.0 installed.

Can anyone help me fix this problem? Many thanks in advance.

@L-v-M @pfent

[L-v-M]

Hi, thank you for the feedback. I will take a look in the next few days and get back to you as soon as possible.

[L-v-M]

Hi @cwang9208,

I cannot reproduce the problem on Ubuntu 22.04.1 LTS with GCC 11.3.0. I cloned the project from GitHub again. Following the steps in the README, I can run Q1 and Q14 on scale factor 1 with the correct results.
I guess it's a configuration problem. Unfortunately, I don't remember if I had a similar issue, and if yes, how I resolved it. Perhaps it's related to the ulimit settings? The next paragraph is taken from the README at https://github.com/axboe/liburing.

ulimit settings

io_uring accounts memory it needs under the rlimit memlocked option, which
can be quite low on some setups (64K). The default is usually enough for
most use cases, but bigger rings or things like registered buffers deplete
it quickly. root isn't under this restriction, but regular users are. Going
into detail on how to bump the limit on various systems is beyond the scope
of this little blurb, but check /etc/security/limits.conf for user specific
settings, or /etc/systemd/user.conf and /etc/systemd/system.conf for systemd
setups. This affects 5.11 and earlier, new kernels are less dependent
on RLIMIT_MEMLOCK as it is only used for registering buffers.

I hope that helps. I also updated the README and removed some of the issues with CMake that I carelessly introduced some time ago.