This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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

Re: Finalised PASC 1003.1 Interpretation #118


Mark Brown <bmark@us.ibm.com> writes:

> > Interpretation response
> > ------------------------
> > No this sentence applies only to aio_fsync().
> > 
> > Rationale
> > -------------
> > For this function only, only the aio_fildes and aio_sigevent fields
> > of the AIO control block are used; the rest are ignored since no
> > seeking , (specific) writing, or reading takes place in this operation.

I still see the need for further clarification.  The problem is when
the fsync operation is performed.  There are several possibilities:

- the fsync() happens immediately when it is issued.  This is everything
  but useful since there might be operations for the descriptor being
  worked on in this very moment

- the fsync() request is queued at after all existing requests (regardless
  of priority) and new requests are never scheduled before the fsync()
  (again, regardless of priority)

  This is not only quite expensive to implement (it's not a simple
  priority queue anymore) it's also leading to lower-priority I/O
  being performed before high-priority I/O.

- the fsync() operation is performed once all operations for the descriptor
  are finished.  This has the problem that the aio_fsync() call can block
  indefinitely.


I really don't know what is the right answer.  I for one assign a
priority to the sync requests and queue them appropriately.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------


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