Feature/io uring - #224

Thanks for taking the time to put this together — io_uring is genuinely interesting territory for a disk-IO-heavy app like aMule, and the contribution is appreciated. That said, the PR as it stands is not in shape to merge: it would silently corrupt downloads, breaks the build for anyone not setting an undeclared option, and bundles three behavior changes wholly unrelated to io_uring. I'll walk through each in priority order so it's clear what would need to change.

Silent corruption in the io_uring path

The hot-path implementation in FileAutoClose.cpp:340-341 returns true from ReadAtIOUring without checking cqe->res, so a short read (legit at EOF, also possible mid-stream) is reported to the caller as a full-count read. Same in WriteAtIOUring at FileAutoClose.cpp:374-375. For an ed2k client this would surface as hash failures and silent partfile corruption. Interestingly the sibling implementation in FileArea.cpp:240 does check cqe->res == (int)count, so the fix template is right there — but FileAutoClose is the hot path and it's currently the broken one.

Related, the same two functions call m_file.fd() (which bumps m_locked) and never Unlock() on the success path — file lock-count leaks per read/write. FileArea's version Unlocks correctly; FileAutoClose's does not.

Build-breaking change for everyone

CMakeLists.txt wraps include (cmake/boost.cmake) in if (ENABLE_BOOST) but ENABLE_BOOST is never declared as an option anywhere. Default-undefined → boost is silently skipped → the build breaks for anyone not passing -DENABLE_BOOST=ON. aMule needs boost (AsioService), so this is a hard fail by default.

Undocumented scope creep

Beyond io_uring the PR also smuggles in:

• An aggressive socket teardown in amule.cpp:902-922 (deletes ECServerHandler, serverconnect, listensocket, clientudp on every non-first ReinitializeNetwork). The existing TODO comment intentionally leaked because those objects can still be referenced by in-flight callbacks/threads — this is potential UAF territory.
• A 5-minute UPnP retry loop in OnCoreTimer that re-maps ports when firewalled. Behavior change for every UPnP user.
• A new top-level build_amule_headless.sh that wipes build/, configures, builds, then sudo make installs.
• Cosmetic edits in mmap code ((uint8_t*) p → static_cast<uint8_t*>(p)) and several stray blank lines in src/CMakeLists.txt, src/amule.cpp, src/amule.h.

Single-platform feature

aMule is cross-platform (Linux, macOS, Windows, *BSD). io_uring is Linux-only — not a hard barrier, optional features behind #ifdef are fine in this codebase, but the value-per-maintenance-cost is lower when only one platform benefits. Worth thinking about whether an asio-backed cross-platform async-IO refactor would be a better use of the same effort (it would also work on macOS/Windows and would integrate with the existing CAsioService).

Perf claims — methodology please

The PR description says "drastically improve disk I/O performance during uploads and downloads", but the implementation does io_uring_submit_and_wait(ring, 1) on an 8-SQE ring — one op per syscall, blocking. That's essentially a pread() with extra steps; none of io_uring's actual perf levers (batching, polled mode, SQPOLL, fixed buffers, registered files) are engaged.

Could you share:

• How you measured the improvement (workload, file sizes, concurrency, disk type)
• Before/after numbers in a code block (not screenshots) — e.g. iostat -x 1 over a sustained download, perf stat -e cs,page-faults,syscalls:sys_enter_pread64,syscalls:sys_enter_io_uring_enter
• The aMule rev tested, kernel version, liburing version, FS type

Without that it's hard to reconcile the claimed gain with what the code actually does.

Style / packaging

A few smaller items to clean up regardless:

• option(ENABLE_IO_URING ... ON) should default OFF — opt-in experimental feature, missing dep would otherwise hard-fail every Linux builder without liburing-dev. The hard-fail-on-=YES-missing behavior is correct per our gating policy; just the default needs to flip.
• target_compile_definitions(muleappcore PUBLIC USE_IO_URING) — should be PRIVATE; no external consumer needs the symbol.
• Two duplicate ThreadLocalRing structs (one in FileArea.cpp, one in FileAutoClose.cpp) — same thread ends up with two rings. Factor out a single shared definition.
• Spanish source comments (# Detectamos manualmente la librería, // Aumenta m_locked, // Fallback clásico..., // esto está en aMule...) — codebase comment language is English.
• Emojis in message(STATUS …) / AddDebugLogLineN (✔️ ❌ 🔁) — not used elsewhere in the project's build output or logs.
• Commented-out debug logs and a typo (Writting) in the io_uring branches.

Suggested next step

This is an I/O optimisation PR — please remove everything that isn't io_uring from it. Specifically: drop the ReinitializeNetwork teardown, the UPnP retry loop, the ENABLE_BOOST gate, the build_amule_headless.sh script, and the cosmetic edits to the mmap path. Then address the silent-corruption fix, flip the option default to OFF, and reply with the benchmark methodology + numbers so the perf claim can be validated. Once the diff is scoped to io_uring alone and the correctness issues are fixed, we can take another look.

Thank you so much for the incredibly thorough and constructive review!

After carefully reading your feedback and re-evaluating the implementation, I realize you are completely right. Since this code uses io_uring_submit_and_wait(ring, 1), it is functionally just a synchronous 1:1 wrapper around pread/pwrite. It misses out entirely on the real performance levers of io_uring (like batching and SQPOLL). The performance claims I initially made were definitely misguided for this synchronous approach.

Furthermore, retrofitting a true asynchronous, batched I/O model into aMule's current disk path would require a massive architectural rewrite of the core. As you wisely pointed out, if an effort of that magnitude is going to be undertaken, it makes much more sense to build it around a Boost.ASIO-backed solution that benefits all platforms (Windows/macOS/Linux) rather than maintaining a complex, Linux-only subsystem.

I'm closing this PR to avoid polluting the codebase with a single-platform feature that doesn't provide tangible async benefits yet. I really appreciate the time you took to point out the silent corruption flaws and the scope creep—it's been a great learning experience.

Thanks again for steering me in the right direction!