https://bugs.kde.org/show_bug.cgi?id=476887
--- Comment #6 from asom...@gmail.com --- Thanks for the quick work! > async reads are more complicated since we can't use the post-syscall, we need > something else to know when to mark the memory as initialized. A conforming implementation of async_read could be fully synchronous. In fact, that's what DragonflyBSD does. Could valgrind cheat a bit and assume that all async_read calls complete as soon as the syscall is done? It wouldn't catch a "user read memory before aio_error indicated completion" bug, but it would still catch the usual errors like out-of-bounds reads. > 1. the global flag looks unsafe if two or more aio_reads are in flight Definitely a problem. POSIX AIO isn't very useful if you can't have multiple reads in flight. > 2. I don't think that the user is obliged to call aio_return. To me that just > seems like an async error code - lots of software doesn't bother to check > error codes. Actually, the user _is_ obliged to call aio_return (except when using aio_waitcomplete, as you observed). That's because aio_return also releases some resources in-kernel. If the user never calls it, their program will probably hang eventually. There is a proposed code change to eliminate the requirement when using kqueue, but it isn't merged yet (https://reviews.freebsd.org/D33144). > Can you confirm that after any of the 3 above the read will have completed > and the memory should be marked as initialized? > Back to the vector versions. I suppose that all of the above ways to indicate > completion also apply and that they are atomic (that is they only apply when > all of the vector of memory blocks have been read to). Yep, they're just as atomic as readv and writev. Yes, if the user calls aio_return too. Without that, you can't know whether the read was successful. -- You are receiving this mail because: You are watching all bug changes.
