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.
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
