From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461)

Description of problem:
i've attached a program [written by Steve Huston shuston] which is 
only C/C++ (no ACE) and
reproduces the
problem with AIO on Linux. It has compilation
instructions in it.
This program opens a socket back to itself - there's a client
and server.
The client sends some data; the server reads it and sends it
back. When the
client receives the echo, it starts the process over again,
counting how
many times it goes around.

There is one command line argument - the number of
iterations to run
through. On each successful iteration, the client prints a
"." to the
terminal. If it completes all of the iterations, it exits. If
it goes for
more than 2 seconds with no AIO activity, it will print an
error message and
sleep for 5 minutes. This gives you an opportunity to attach
to it with gdb
and examine the threads. One will be stuck in libc_read, and
if you also do
a "netstat" you'll see there is data available to read, but
it's not being
read. This is the same condition we see in ACE.

It won't run correctly in gdb - it runs the machine out of
threads and runs
very slowly. This is why you need to wait for it to lock up
and then attach
to it.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. g++ -g -o aiotest -lrt aiotest.cpp
2. run  "./aiotest 1000000" few times
	

Actual Results:  many times I get "Resorce temporarily unavailable"

Expected Results:  "AIOCB test successful"

Additional info:

the statistic is better for RH AS 2.1, but even here it doesn't work 100%.