asynchronous I/O

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

asynchronous I/O

useche
Hi Guys,

I have been looking for information on how to do asynchronous I/Os in
OBSD with no luck. The only thing I have found so far is the O_ASYNC
flag in the fcntl syscall. I couldn't find any manual that talks about
this. Is this functionality included in OBSD?. If so, where can I find
information?

Thanks in advance,
Luis

Reply | Threaded
Open this post in threaded view
|

Re: asynchronous I/O

Nick Guenther
On Thu, Dec 3, 2009 at 10:57 PM, Luis Useche <[hidden email]> wrote:
> Hi Guys,
>
> I have been looking for information on how to do asynchronous I/Os in
> OBSD with no luck. The only thing I have found so far is the O_ASYNC
> flag in the fcntl syscall. I couldn't find any manual that talks about
> this. Is this functionality included in OBSD?. If so, where can I find
> information?
>

Well, open(2) mentions "If the O_SYNC flag is set, all I/O operations
on the file will be done synchronously.", so I suppose we're supposed
to assume the default is O_ASYNC. But I suspect what you're really
looking for is select(2).

-Nick

Reply | Threaded
Open this post in threaded view
|

Re: asynchronous I/O

Ted Unangst-2
On Thu, Dec 3, 2009 at 11:47 PM, Dope Ice Apollyon the Third
<[hidden email]> wrote:

> On Thu, Dec 3, 2009 at 10:57 PM, Luis Useche <[hidden email]> wrote:
>> Hi Guys,
>>
>> I have been looking for information on how to do asynchronous I/Os in
>> OBSD with no luck. The only thing I have found so far is the O_ASYNC
>> flag in the fcntl syscall. I couldn't find any manual that talks about
>> this. Is this functionality included in OBSD?. If so, where can I find
>> information?
>>
>
> Well, open(2) mentions "If the O_SYNC flag is set, all I/O operations
> on the file will be done synchronously.", so I suppose we're supposed
> to assume the default is O_ASYNC. But I suspect what you're really
> looking for is select(2).

He's probably looking for aio_read and aio_write and such, but as one
can tell by the absence of man pages, they don't exist here.

Reply | Threaded
Open this post in threaded view
|

Re: asynchronous I/O

useche
On Fri, Dec 4, 2009 at 12:07 AM, Ted Unangst <[hidden email]> wrote:

> On Thu, Dec 3, 2009 at 11:47 PM, Dope Ice Apollyon the Third
> <[hidden email]> wrote:
>> On Thu, Dec 3, 2009 at 10:57 PM, Luis Useche <[hidden email]> wrote:
>>> Hi Guys,
>>>
>>> I have been looking for information on how to do asynchronous I/Os in
>>> OBSD with no luck. The only thing I have found so far is the O_ASYNC
>>> flag in the fcntl syscall. I couldn't find any manual that talks about
>>> this. Is this functionality included in OBSD?. If so, where can I find
>>> information?
>>>
>>
>> Well, open(2) mentions "If the O_SYNC flag is set, all I/O operations
>> on the file will be done synchronously.", so I suppose we're supposed
>> to assume the default is O_ASYNC. But I suspect what you're really
>> looking for is select(2).
>
> He's probably looking for aio_read and aio_write and such, but as one
> can tell by the absence of man pages, they don't exist here.

Exactly, I am more interested more in something close to aio_read &
aio_write. I was hoping there was some api I can use. Is there any
reason why POSIX aio does not exist in OBSD? Security reasons maybe?

Luis.

Reply | Threaded
Open this post in threaded view
|

Re: asynchronous I/O

Nick Guenther
On Fri, Dec 4, 2009 at 10:20 AM, Luis Useche <[hidden email]> wrote:

> On Fri, Dec 4, 2009 at 12:07 AM, Ted Unangst <[hidden email]> wrote:
>> On Thu, Dec 3, 2009 at 11:47 PM, Dope Ice Apollyon the Third
>> <[hidden email]> wrote:
>>> On Thu, Dec 3, 2009 at 10:57 PM, Luis Useche <[hidden email]> wrote:
>>>> Hi Guys,
>>>>
>>>> I have been looking for information on how to do asynchronous I/Os in
>>>> OBSD with no luck. The only thing I have found so far is the O_ASYNC
>>>> flag in the fcntl syscall. I couldn't find any manual that talks about
>>>> this. Is this functionality included in OBSD?. If so, where can I find
>>>> information?
>>>>
>>>
>>> Well, open(2) mentions "If the O_SYNC flag is set, all I/O operations
>>> on the file will be done synchronously.", so I suppose we're supposed
>>> to assume the default is O_ASYNC. But I suspect what you're really
>>> looking for is select(2).
>>
>> He's probably looking for aio_read and aio_write and such, but as one
>> can tell by the absence of man pages, they don't exist here.
>
> Exactly, I am more interested more in something close to aio_read &
> aio_write. I was hoping there was some api I can use. Is there any
> reason why POSIX aio does not exist in OBSD? Security reasons maybe?
>

Not to disparage your choice of API, but you've got me wondering: does
anyone actually use AIO? The best result I could find on koders.com
was a line from nginx that called a function whose name ended in _aio.
Everything else was just various other APIs that provide AIO as a
backend.

-Nick

Reply | Threaded
Open this post in threaded view
|

Re: asynchronous I/O

Ted Unangst-2
In reply to this post by useche
On Fri, Dec 4, 2009 at 10:20 AM, Luis Useche <[hidden email]> wrote:

> Exactly, I am more interested more in something close to aio_read &
> aio_write. I was hoping there was some api I can use. Is there any
> reason why POSIX aio does not exist in OBSD?

Nobody wrote it.

Reply | Threaded
Open this post in threaded view
|

Re: asynchronous I/O

Todd T. Fries-2
In reply to this post by Nick Guenther
Penned by Dope Ice Apollyon the Third on 20091204 10:43.03, we have:
| On Fri, Dec 4, 2009 at 10:20 AM, Luis Useche <[hidden email]> wrote:
| > On Fri, Dec 4, 2009 at 12:07 AM, Ted Unangst <[hidden email]> wrote:
| >> On Thu, Dec 3, 2009 at 11:47 PM, Dope Ice Apollyon the Third
| >> <[hidden email]> wrote:
| >>> On Thu, Dec 3, 2009 at 10:57 PM, Luis Useche <[hidden email]> wrote:
| >>>> Hi Guys,
| >>>>
| >>>> I have been looking for information on how to do asynchronous I/Os in
| >>>> OBSD with no luck. The only thing I have found so far is the O_ASYNC
| >>>> flag in the fcntl syscall. I couldn't find any manual that talks about
| >>>> this. Is this functionality included in OBSD?. If so, where can I find
| >>>> information?
| >>>>
| >>>
| >>> Well, open(2) mentions "If the O_SYNC flag is set, all I/O operations
| >>> on the file will be done synchronously.", so I suppose we're supposed
| >>> to assume the default is O_ASYNC. But I suspect what you're really
| >>> looking for is select(2).
| >>
| >> He's probably looking for aio_read and aio_write and such, but as one
| >> can tell by the absence of man pages, they don't exist here.
| >
| > Exactly, I am more interested more in something close to aio_read &
| > aio_write. I was hoping there was some api I can use. Is there any
| > reason why POSIX aio does not exist in OBSD? Security reasons maybe?
| >
|
| Not to disparage your choice of API, but you've got me wondering: does
| anyone actually use AIO? The best result I could find on koders.com
| was a line from nginx that called a function whose name ended in _aio.
| Everything else was just various other APIs that provide AIO as a
| backend.
|
| -Nick

Unfortunately qemu has aio support.

Fortunately, enough other os's do not have aio that they have code to
handle their needs without aio support.
--
Todd Fries .. [hidden email]

 _____________________________________________
|                                             \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
| 2525 NW Expy #525, Oklahoma City, OK 73112  \  sip:[hidden email]
| "..in support of free software solutions."  \  sip:[hidden email]
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt

Reply | Threaded
Open this post in threaded view
|

Re: asynchronous I/O

Bob Beck-4
In reply to this post by Ted Unangst-2
2009/12/4 Ted Unangst <[hidden email]>:
> On Fri, Dec 4, 2009 at 10:20 AM, Luis Useche <[hidden email]> wrote:
>
>> Exactly, I am more interested more in something close to aio_read &
>> aio_write. I was hoping there was some api I can use. Is there any
>> reason why POSIX aio does not exist in OBSD?
>
> Nobody wrote it.
>
>

And:

APPLICATION USAGE

    The aio_read() function is part of the Asynchronous Input and
Output option and need not be available on all implementations.

Reply | Threaded
Open this post in threaded view
|

Re: asynchronous I/O

Ted Unangst-2
In reply to this post by Todd T. Fries-2
On Fri, Dec 4, 2009 at 1:34 PM, Todd T. Fries <[hidden email]> wrote:
> Unfortunately qemu has aio support.

Does it really need it?  I cooked up a basic userland implementation
using pthreads last night.

Reply | Threaded
Open this post in threaded view
|

Re: asynchronous I/O

Todd T. Fries-2
Penned by Ted Unangst on 20091204 16:30.57, we have:
| On Fri, Dec 4, 2009 at 1:34 PM, Todd T. Fries <[hidden email]> wrote:
| > Unfortunately qemu has aio support.
|
| Does it really need it?  I cooked up a basic userland implementation
| using pthreads last night.

They provide compatibility functions #ifndef AIO_SUPPORT, which in my book
means they don't.

someone> Ya. QEMU made the POSIX AIO support optional for older OS's and OS's without support... but it also helps QEMU performance quite a bit.
someone> AIO is useful for VMs, proxy servers, web servers and a few other types of apps.
todd> I guess I don't get what the difference between AIO and non blocking fd's are.

I'd be more keen on getting current qemu working than getting
an aio implementation specifically for qemu.

Does aio really require threading?

If you did implement aio using threads, it would be the first use of threading
in all of base.

Thanks,
--
Todd Fries .. [hidden email]

 _____________________________________________
|                                             \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
| 2525 NW Expy #525, Oklahoma City, OK 73112  \  sip:[hidden email]
| "..in support of free software solutions."  \  sip:[hidden email]
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt

Reply | Threaded
Open this post in threaded view
|

Re: asynchronous I/O

Ted Unangst-2
On Fri, Dec 4, 2009 at 4:45 PM, Todd T. Fries <[hidden email]> wrote:
> Does aio really require threading?

In some sense, yes, in others, no.  aio is designed so you don't need
(userland) threads.

"Normally" you'd write your server to use non-blocking io.  But that
doesn't work with files on disk.  How can it?  With network sockets,
you have somebody on the other end pushing data into your pipe which
the kernel buffers.  But the file system isn't going to read stuff
from disk until you ask for it, there's no "somebody else" pushing
data at you.  That's what aio is for.  It starts up a disk request
without waiting for it.  Then you can come back and get the result.
Think of it as preemptive polling.  Instead of calling select()/poll()
to find out what's _ready_ for io, you call aio and then later it
tells you what's _done_ with io.

A normal implementation would be purely kernel based, with a few new
syscalls.  But the kernel would still need to keep track of all the
buffers and io requests.  So at that level, there's still something
resembling threading.

This is all fairly easy to fake in userland.  When somebody calls
aio_read(), just spin up a thread that calls read() until done.  The
main process goes on with its work, magic happens in the background.
Of course, this requires the ability for one thread to execute while
another is blocked, which the uthreads implementation we have doesn't
have.

Reply | Threaded
Open this post in threaded view
|

Re: asynchronous I/O

useche
Iguess the short answers is that it is not implemented and probably it won't.

There are certain applications that would certainly benefit from aio.
The one I can think of (it is the one I use the most) is I/O trace
replay. But I am sure that there are plenty of applications that can
benefit from this facility.

It is true that aio can be easily implemented having an I/O handler
thread. But it is always nice to have a library that do it for you ;)

Thanks for your responses,
Luis

On Fri, Dec 4, 2009 at 5:45 PM, Ted Unangst <[hidden email]> wrote:

> On Fri, Dec 4, 2009 at 4:45 PM, Todd T. Fries <[hidden email]> wrote:
>> Does aio really require threading?
>
> In some sense, yes, in others, no.  aio is designed so you don't need
> (userland) threads.
>
> "Normally" you'd write your server to use non-blocking io.  But that
> doesn't work with files on disk.  How can it?  With network sockets,
> you have somebody on the other end pushing data into your pipe which
> the kernel buffers.  But the file system isn't going to read stuff
> from disk until you ask for it, there's no "somebody else" pushing
> data at you.  That's what aio is for.  It starts up a disk request
> without waiting for it.  Then you can come back and get the result.
> Think of it as preemptive polling.  Instead of calling select()/poll()
> to find out what's _ready_ for io, you call aio and then later it
> tells you what's _done_ with io.
>
> A normal implementation would be purely kernel based, with a few new
> syscalls.  But the kernel would still need to keep track of all the
> buffers and io requests.  So at that level, there's still something
> resembling threading.
>
> This is all fairly easy to fake in userland.  When somebody calls
> aio_read(), just spin up a thread that calls read() until done.  The
> main process goes on with its work, magic happens in the background.
> Of course, this requires the ability for one thread to execute while
> another is blocked, which the uthreads implementation we have doesn't
> have.

Reply | Threaded
Open this post in threaded view
|

Re: asynchronous I/O

gwes-2
In reply to this post by useche
Long ago I worked in the kernel of a BSD which supported async (disk) I/O.
The internals did use a kernel thread for queueing and reporting.
There was one per process using AIO because it made life simpler:
   each page which was mentioned in AIO had to be pinned,
      and "blaming" that on the AIO thread was easy.
   similarly, there was "someone to talk to" when the I/O completed.

Useful? It made architecting correct replacements for thread-using
catastrophes -much- easier. Implement a work queue in the user program
and -never- block anywhere except in one timer poll() in the middle.

As I remember, it didn't take much code to implement, and
in the architecture as I remember it, kernel threads were cheap.

  geoff steckel
  very-ex Alliant Computer