2002-08-16 13:34:38

by Dan Kegel

[permalink] [raw]
Subject: Re: aio-core why not using SuS? [Re: [rfc] aio-core for 2.5.29 (Re: async-io API registration for 2.5.29)]

Suparna Bhattacharya wrote:
>
> On Thu, Aug 15, 2002 at 09:42:25PM -0400, Benjamin LaHaise wrote:
> > > Now reading the SuS specifications I also like less and less our current
> > > kernel API of this sumbit_io, the SuS does exactly what I suggested
> > > originally that is aio_read/aio_write/aio_fsync as separate calls. So
> > > the merging effect mentioned by Ben cannot be taken advantage of by the
> > > kernel anyways because userspace will issue separate calls for each
> > > command.
> >
> > Read it again. You've totally missed lio_listio. Also keep in mind what
> >
>
> Also, wasn't the fact that the API was designed to support both POSIX
> and completion port style semantics, another reason for a different
> (lightweight) in-kernel api? The c10k users of aio are likely to find
> the latter model (i.e. completion ports) more efficient.

You can actually consider posix AIO using sigtimedwait() to pick up completion
notices to fit the definition of completion port if you squint a bit.
(The patented scheduler magic of NT completion ports is just a fun extra...)
- Dan


2002-08-16 14:19:35

by Jamie Lokier

[permalink] [raw]
Subject: Re: aio-core why not using SuS? [Re: [rfc] aio-core for 2.5.29 (Re: async-io API registration for 2.5.29)]

Dan Kegel wrote:
> You can actually consider posix AIO using sigtimedwait() to pick up
> completion notices to fit the definition of completion port if you
> squint a bit.

... with the bonus that it fits comfortably into a sigtimedwait() loop
that's waiting for non-AIO things too.

-- Jamie

2002-08-16 14:38:40

by Benjamin LaHaise

[permalink] [raw]
Subject: Re: aio-core why not using SuS? [Re: [rfc] aio-core for 2.5.29 (Re: async-io API registration for 2.5.29)]

On Fri, Aug 16, 2002 at 03:21:33PM +0100, Jamie Lokier wrote:
> Dan Kegel wrote:
> > You can actually consider posix AIO using sigtimedwait() to pick up
> > completion notices to fit the definition of completion port if you
> > squint a bit.
>
> ... with the bonus that it fits comfortably into a sigtimedwait() loop
> that's waiting for non-AIO things too.

The idea was to make completion events as light weight as possible -- they
can be read from the queue without even entering kernel space. Support for
getting multiple completion events is also needed (sigtimed wait only pulls
one signal at a time). Nothing is stopping us from adding support to do
an async sigtimedwait that provides a completion event when a signal arrives.

-ben
--
"You will be reincarnated as a toad; and you will be much happier."