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.
I'm not native english speaker, so when arguing about wording, my understanding may not be correct. But I personally understand this as: aio_error() may fail => it's not hard requirment and it's upon implementation what would happen -- Cyril Hrubis [email protected] ------------------------------------------------------------------------------ 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
