Date: Wed, 21 Apr 1999 20:34:37 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Christopher Sedore <cmsedore@mailbox.syr.edu> Cc: hackers@FreeBSD.ORG Subject: Re: aio_suspend() functionality Message-ID: <19990421203437.35158@hydrogen.nike.efn.org> In-Reply-To: <Pine.SOL.3.95.990421215301.26724A-100000@rodan.syr.edu>; from Christopher Sedore on Wed, Apr 21, 1999 at 10:25:18PM -0400 References: <Pine.SOL.3.95.990421215301.26724A-100000@rodan.syr.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Christopher Sedore scribbled this message on Apr 21: > > I sent a message a day or two ago asking if anyone had looked into > changing the behavior of aio_suspend so that it did not require a list of > aiocb's, but rather would accept an array of null pointers, and then fill > them in for you when an operation completed. > > A patch to vfs_aio.c that does just this is available at > ftp://ftp.maxwell.syr.edu/freebsd/vfs_aio.c-aio_suspend-patch thanks for doing the work.... > Why would one care about this? If one were going to have hundreds (or > thousands) of outstanding asynchronous IO requests, it isn't very I wish this was possible.. you can only queue 256 and have 32 active at once right now... sounds like we need to LINT some more options for this... > efficient to handle them buy building arrays of pointers to control blocks > and then polling each one to determine whether or not it has completed, > particularly since the kernel already has them in a handy list. > > It essentially allows you to use aiocb's as fire and forget: malloc one > (possibly "growing it" to keep your own state), give it to the OS with > aio_read/aio_write, then simply poll for completed events using > aio_suspend. When an operation completes, you'll get the pointer to the > aiocb back. > > This patch is against FreeBSD 3.1-STABLE It works in my testing, and > is not entirely backwardly compatible with the old aio_suspend (it won't > behave the same way if you pass in an array of all NULL pointers, > otherwise it should be functionally equivalent). I've been trying to get Dyson's attention about aio too... there is one major problem with the code that allows any user that can do aio to panic the system... also it doesn't honor the FREAD flag on a descriptor... if you have a descriptor open just for writing, you can read from it with aio... I have fixes for both of these bugs... but right now I don't have a machine to do -current testing on, so I won't be able to throughly be able to test the patches... > The patch will generate a warning during compiling because the upper > layers pointing to aio_suspend expect the array of pointers to be a const, > and I deconstify it. we should find out what DG and bde think about this change... it is a nice change, though we need to evaluate what it does to the standard.. one thing we might look at is just using a new aio_sleep function that provides this functionality... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990421203437.35158>