Re: async-io

Adrian Chadd wrote:

> Under FreeBSD it'd probably work better to use the posix AIO or
> the kqueue stuff, under Linux it'd probably work better to
> useclone()/threads, under Solaris libaio might bethe best choice ..
> Implementing disk as the underlying mechanism forces me to clean up
> the storage manager and its use of memory first, which isn't a bad
> thing.

Some comments:

Squids async-io is implemented because Posix AIO cannot do what Squid
requires, and also because Solaris AIO implementation at the time did
not manage to keep up with it in a stable manner.

One major shortcoming of Posix AIO is that it doesn't define AIO
operations for open/close. Only read/write/cancel/sync are defined. The
other major shortcoming is in how it signals completetion.

I think the FreeBSD implementation has extended AIO with open/close
calls, but if not then you probably want to use some other alternative
like diskd.

async-io (or aiops.c) is a Posix threads based AIO like implementaion
implementing open/close/read/write/cancel/stat/unlink/sync. On top of
that there is a callback handling layer (async_io.c).

Since aiops.c isn't really AIO the two layers should probably be merged
into one layer. The reasons why it is separated in two is that Stewart
wanted to have a "userspace" vs "kernel" separation where data is copied
to protect himself from aborts changing the data under the feets of an
ongoing operations, but as you say you are working with fixing this
issue of the store magager it shouldn't be that much of an issue.

/Henrik
Received on Sun Apr 23 2000 - 06:26:23 MDT