On Tue, Oct 26, 2010 at 1:40 PM, Garrett Cooper <[email protected]> wrote:
> On Tue, Oct 26, 2010 at 9:16 AM, Cyril Hrubis <[email protected]> wrote:
>> Hi!
>>> > I've been reading POSIX documentation for some time now and even reading
>>> > glibc source code and the result is that aio_error/3-1.c doesn't test
>>> > anyting and should be removed.
>>> >
>>> > The test is trying to assert EINVAL from aio_error accordingly to:
>>> >
>>> > http://www.opengroup.org/onlinepubs/009695399/functions/aio_error.html
>>> >
>>> > ...
>>> >
>>> > The aio_error() function may fail if:
>>> >
>>> > [EINVAL]
>>> > The aiocbp argument does not refer to an asynchronous
>>> > operation whose return status has not yet been retrieved.
>>> >
>>> > ...
>>> >
>>> >
>>> > As far as I understand this, it's says you may get EINVAL if you call
>>> > aio_error() on finished aiocb second (and more) times.
>>> >
>>> > This is implemented on linux as "return aiocb->__error_code" so IMHO
>>> > there is no way to test this.
>>>
>>> I think that the original developers misinterpreted the test
>>> requirements. aio_error is _always_ supposed to return errno values,
>>> not -1 and set the global errno. Otherwise it wouldn't make sense
>>> because asynchronous I/O would be more synchronous than anything else.
>>
>> This is not the only problem here. Accordinly to POSIX aio_error() output is
>> defined only when you pass correct aiocb (that means struct aiocb that is
>> already used for some aio_{write,read,fsync,...}) and the value may not be
>> stored pernamently, so if you read it once, it could return EINVAL second
>> time.
>>
>>
>> ...
>>
>> memset (&aiocb, 0, sizeof (struct aiocb));
>>
>> aiocb.aio_fildes = fd;
>> aiocb.aio_buf = buf;
>> aiocb.aio_reqprio = -1;
>> aiocb.aio_nbytes = BUF_SIZE;
>>
>> /*
>> * Here return from aio_error() is not defined as
>> * there was no aio operation done on aiocb.
>> *
>> * On linux you get value that is stored in struct aiocb->__error_code
>> * and as aiocb is filled with zeroes on the beginning, this
>> * returns also zero.
>> */
>> ret = aio_error(&aiocb);
>>
>> if (aio_write(&aiocb) == -1) {
>> /* quening write operation has failed */
>> return 1;
>> }
>>
>> /*
>> * Wait for completion.
>> */
>> while ((ret = aio_error(&aiocb)) == EINPROGRESS)
>> sleep(1);
>>
>> /* Here we have status from aio_write in ret */
>>
>> /*
>> * And here we may get EINVAL instead of status from previous
>> * aio_write()
>> */
>> ret = aio_error(&aiocb);
>>
>>
>> So what I'm saying is that if you really want to write correct test for 3-1.c
>> you need to:
>>
>> 1. Create aio data transfer
>> 2. Wait for completion
>> 3. Get aio return status by aio_error()
>> 4. Get it once more and it should either be EINVAL or same value that you
>> got first time.
>>
>> Which seems to be a little dumb to test to me, so I vote for removing 3-1.c
>> from ltp.
>
> I'll do some comparison with other existing testcases, as well as
> look at the requirements for 3-1 further tonight -- but my initial
> look at your argument seems sound.
Looking at the tort again in SUSv4, the logic that you're arguing
seems incorrect:
The aio_error() function may fail if:
[EINVAL]
The aiocbp argument does not refer to an asynchronous
operation whose return status has not yet been retrieved.
It's pretty blatant that EINVAL should apply to aio_error when
aiocbp is passed in which doesn't point to a valid file descriptor
linked to some sort of aio operation. If Linux is improperly caching
the aio_error, then Linux needs to be corrected to meet the POSIX
requirements if the test is supposed to pass and the behavior isn't
already documented in the OS specific documentation (manpages,
whatever). Same thing applies for all OSes trying to meet the golden
POSIX standard.
The ERROR clause's wording is lousy though, so I'll bring this up
with opengroup.
Thanks,
-Garrett
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
