That's a cute trick. The ultimate solution is to implement a semi-synchronous message passing API to replace the myrid system calls we have now. Roughly speaking, what the Amiga did for messages, ports, and I/O, is far superior then what is done in Linux and *BSD. You get the benefit of being able to operate syncnronously when possible, and having a convenient cup-holder for the operation state if you decide you have to 'block' the operation (instead of the state being strewn all over the call stack in a syscall implementation). Userland can decide whether to block or not block on an operation entirely independant of the OS deciding whether to block or not block on an operation.
-Matt Matthew Dillon <[EMAIL PROTECTED]> :Without wanting to get too far off into the weeds, squid does something :interesting. They need to be able to nonblock for everything including :open(), read(), unlink(), readdir() etc. So what they do is implement a :fairly significant superset of the traditional AIO stuff using pthreads. It :seems to work pretty well for them, even with linuxthreads style threads. :Granted, squid's needs are not exactly typical. But I did want to point :out that a good part of the delays come not only from data IO but operations :like opening a file (pathname traversal), creating or removing a file, :reading a directory etc. This is a particular problem when the disk :is really busy. : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] :"All of this is for nothing if we don't go to the stars" - JMS/B5 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"