In message <[EMAIL PROTECTED]>, you wrote: >Sorry, but there is nothing in FreeBSD that will let you program in the >method you would like to do...
Well, _if_ there were a full and complet family of aio_*() functions implemented in the FreeBSD kernel, _then_ I could indeed program in the style I've described. >Also, going aio_ as implemented in FreeBSD will be guaranteed to perform >worse than kqueue/kevent.. I understand that, and I don't care. As I noted earlier, for some applications, performance of these particular operations is a non- issue. >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!) >FreeBSD's kernel is inherently syncronous... Well, surely not entirely. I mean it fields interrupts, right? >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? >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. _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"