This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: BUG REPORT: aio with fork
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Rajat Kateja <rkateja at cmu dot edu>, <libc-alpha at sourceware dot org>
- Cc: <nd at arm dot com>
- Date: Thu, 14 Jul 2016 12:03:24 +0100
- Subject: Re: BUG REPORT: aio with fork
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <CANdRqxKXcpMCvRkyVvagB6yi++MJ3tkWLWSkkJgoPsqm0tFbNw@mail.gmail.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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.)