Date: Fri, 22 Oct 2004 10:27:59 -0700 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: Andre Oppermann <andre@freebsd.org> Subject: Re: aio_connect ? Message-ID: <20041022172759.GX22681@funkthat.com> In-Reply-To: <78978.1098303754@monkeys.com> References: <20041020031931.GP22681@funkthat.com> <78978.1098303754@monkeys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ronald F. Guilmette wrote this message on Wed, Oct 20, 2004 at 13:22 -0700:
> >This is because aio_ requires a kernel thread
> >to wait for you instead of your process context.. Currently we are limited
> >to only executing 4 aio_ events at once.. This can be increased, but will
> >incure a stack for each additional thread you want to run...
>
> That's OK. I don't mind. At least I don't think that I mind. (How big
> must the separate event handler stacks be? If they are only, say, 2kB
> apiece, then that's no big deal. Heck, my lowly desktop machine has a
> zillion times that much main memory now!)
The stacks are at least 8KB.. (but I think 12KB), plus any associated
struct proc and other associated data... there is a tunable to increase
the four, but of course, you'll take up more memory..
> >FreeBSD's kernel is inherently syncronous...
>
> Well, surely not entirely. I mean it fields interrupts, right?
I'm talking about how it appears from userland.. This entire discussion
has been about userland/kernel interface and nothing more.. bringing
up a kernel/kernel interface is completely different...
> >To handle what you want to do, we would need to completely rearchitect
> >the FreeBSD kernel to make more things asyncronous..
>
> I was under the impression that a lot of work had already gone in that
> general direction in order to support SMP. No?
For a lot of the kernel to kernel stuff, but many paths like ioctl's,
read, write, etc. All those kernel interfaces will block in the kernel
path till the resulting device returns... (is woken up).. There is no
async interface as it hasn't been the Unix way(tm)...
> >Going async can improve things, and with it, makes implementing a sync
> >interface easy on top of it...
>
> Yes. (I realized myself last night that in theory, read(2) and write(2)
> could be implemented, entirely in userland, on top of aio_read() and
> aio_write() respectively.)
>
> >So the short of it is, no, FreeBSD at a low level does not support
> >it...
>
> Oh well. It didn't hurt to ask.
>
> >Now, I know this isn't what you want, but I usually make my kevent
> >use appear as if it's async... I use the udata pointer point to a
> >struct which starts with a function pointer... Then when I get events
> >back from kevent, I just have code that loops over the events, and calls
> >the associated function pointer.. simulating a signal...
>
> I understand. Your event loop is really an event/dispatch loop.
>
> >Hope this helps...
>
> Well, you have certainly helped to clarify for me the various reasons
> why it might be less than a good idea to use aio_*() function calls,
> in abundance, on the current FreeBSD kernel. For that I do thank you.
Even though aio_ needs help, it appears that some other people are
working on improving it right now... Doug Ambrisko posted a message
to -current about some patches to make aio_ work with kqueue.
Brian Feldman did start work on making kqueue's send signals when an
event became available, but it was put on the back burner because of a
problem w/ locking since, that signel could also wake up the kqueue
that delivered the signal.. Though now that kqueue has been locked
down we can revisit this..
Oh, another thing is that there isn't yet a verbose signal delivery
mechanism.. There are only two signals that are for user's use, and
that isn't enough for what you want.. since even if you did get a signal,
it'd degenerate into an event/dispatch loop at you stated above..
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041022172759.GX22681>