This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: aio_suspend from different process than originated aio_read


I hope this is the correct list for this question,
if not please advise.

I am working on a multi-process application 
which uses shared-memory buffer for filesystem operations.
It has tradtionally used ordinary synchronous read() and write().
Now we are experimenting with librt's aio functions,
in particular aio_read,  aio_error,  aio_suspend.
Everything works fine when a single process does all of the above.
But the question concerns two processes:
Note that the aiocb is also in shared memory :
   .  process A issues aio_read
   .  process B wants the block being read and needs to wait for
     completion.        It loops on calling aio_suspend with a
     timeout and eventually it finds the read has completed.

This use of timeout to do polling is documented in man page for aio_suspend :

NOTES
       One can achieve polling by using a non-NULL timeout
       that specifies a zero time interval.

However nowhere in aio man pages is there any statement
permitting or prohibiting multi-process use of an aiocb.

We find that this polling technique done by a different process
works functionally,  except that,  if the read had not completed
on entry to aio_suspend,  then it waits for the full timeout interval
even if,  say,  the read completes half way through that interval.
This is different from when called by originator of aio_read,
where timeout is not needed and aio_suspend completes
as soon as the read completes.
We also find that aio_suspend returns immediately in both cases
(originator and non-originator) if the read was already complete.


 We understand why aio_suspend works this way for a non-originator,
and this behaviour is ok for us performance-wise as this scenario
(different process needs block) is a quite rare occurrence.


The question is simply this:

In a scenario where caller is not the originator of aio_read,
Can we depend on both
  .    aio_suspend()  behaving as I've described it
      (returning immediately if read already complete,  else after timeout expires)
  .    aio_error() returning  correct status e.g. EINPROGRESS or other
?

Or in other words,   is it ok for different proceses to share an aiocb
in shared memory,   subject to the limitation of
aio_suspend will not return immediately as soon as in-flight read completes?


Thanks for any answers or comments
   (including if you think we should do it some other way)

Cheers,     John Lumby
 		 	   		   		 	   		  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]