Testing Posix asynchronous I/O

[Mark Geisert]

Updating my previous post...

>> On Tue, 3 Apr 2018, Corinna Vinschen wrote:
>>> Some testcase (here on cygwin-developers, not as patch) would be
>>> nice, too.
>>
>> I do have a couple already.  One is a (fairly large) test app I have that times
>> various methods of copying the heap from one process to a child. AIO is one of
>> those methods.  I could whittle that down to something using only AIO.  And the
>> Linux man page for aio(7) has a sample program that can test AIO on something
>> other than disk files.

The man page sample program, which does a single aio_read() on each file/device 
named in args, seems to work for all cases except the specific one demonstrated 
there, which is more than one /dev/stdin.  On Cygwin, satisfying the first 
aio_read() causes the second to be satisfied with no input.  On Linux, the 
program waits for each aio_read() to be satisfied in sequence.

> In addition to those two test programs, there's iozone.  That supports AIO
> operations but would need to be ported to Cygwin.  IMNSHO iozone needs a -NG
> re-write.  It is 5 source files, no header files, and 1K of its 30K lines are
> #ifdef's.  And what it calls a Windows build is actually a Cygwin (32-bits)
> build.  But it's there if needed, modulo some work porting it.

I have ported iozone to 64-bit Cygwin (not re-written) and I can see it will be 
very helpful in stress-testing the AIO code.  At the moment I'm debugging an odd 
strace message after many thousands of I/Os:
       0 [sig] iozone 12248 wait_sig: garbled signal pipe data nb 176, sig 0
which seems to say the code is internally sending "signal 0", but there's no 
obvious way that could be occurring.

> The "heap transfer" program I mentioned earlier, heapxfer, allows me to specify
> heap size and number of simultaneous AIOs.  Simple cases, such as staying within
> AIO_MAX AIOs, work fine.  I recently finished debugging a testcase writing 1GB
> of data to a file using 512 AIOs.  So the first AIO_MAX AIOs launched as inline
> AIOs, while the remainder were queued.  Then as worker threads became available,
> they launched inline AIOs themselves.  Found a couple of nits but it's working now.

Most recently with heapxfer I've been testing aio_write()s of 2047MB in 2047 
AIOs on my 2Core/4Thread system.  Found and fixed another obscure buglet.

I will be AFK June 15..25 but wanted to post status since it's been a while 
since my last posting.  Comments welcome but in any case I'll keep testing.
Thanks & Regards,

..mark