This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: BUG REPORT: aio with fork
Thanks. I have filed the bug report here
https://sourceware.org/bugzilla/show_bug.cgi?id=20372. Bug id - 20372.
On Thu, Jul 14, 2016 at 4:03 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> On 13/07/16 18:51, Rajat Kateja wrote:
>> Hi,
>>
>> I think I have hit a bug in the AIO system. I contacted the linux-aio
>> mailing list but was redirected here because I am using posix-aio.
>> Please see the following bug report:
>>
>> One line description: Doing AIO concurrently before and after a fork
>> causes the IOs after the fork to be never queued.
>>
>> Full Description: Consider the scenario.
>>
>> 1. A program issues an aio_read/aio_write
>> 2. After the completion of the aio, the program forks
>> 3. The child process issues an aio_read/aio_write
>>
>> The aio code (from aio_misc.c) maintains a global variable
>> idle_thread_count. Also, aio threads idle for a period of 1 second (by
>> default) after completing the IO operation. During this one second,
>> the parent forks and the child gets the copy of the idle_thread_count
>> from the global data segment. When the child issues a fresh aio
>> request, the code sees that the idle_thread_count is greater than one
>> and signals a condition variable to wake up the thread. But of course,
>> there if no thread in the child process. Hence the AIO stays in the
>> EINPROGRESS state forever.
>>
>
> submit the bug report at https://sourceware.org/bugzilla
> so ppl can keep track of it.
>
> (i believe the aio design in musl libc does not have this problem.)
>
--
Rajat Kateja
Graduate Student
Parallel Data Lab
Carnegie Mellon University