Date: Tue, 2 Dec 1997 06:21:21 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: toor@dyson.iquest.net (John S. Dyson) Cc: tlambert@primenet.com, toor@dyson.iquest.net, current@freebsd.org Subject: Re: FYI: usage of new AIO calls Message-ID: <199712020621.XAA17318@usr08.primenet.com> In-Reply-To: <199712020221.VAA08422@dyson.iquest.net> from "John S. Dyson" at Dec 1, 97 09:21:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> You have to realize what my near term/long term goals are. Firstly, there is > absolutely no reason that the threading mechanism has to be used. I am > NOT using it for my main purpose -- that is RAW I/O. If there is any cause > to, we can abstract the code for sockets or whatever. Each type of device > needs a different kind of handler, and at that point, some kind of switch > scheme would be appropriate. I think that works... mostly. You don't get an aio_recvmsg(), though that you can call on a UDP socket with appropriate options to get the packet header out and know the intended destination of the datagram on a multihomed machine. There are somethings for which aio_read() is simply not general enough. As I said in the other posting, this speaks more to the bad design of the new POSIX standard. > The code as commited proves a couple of things: > > 1) We can do the non-threaded approach. (physio type transfers.) > 2) We can do the threaded approach. (non-physio type transfers.) > > Eventually, we can easily extend the code to avoid kernel threads, except > in exceptional cases. I would greatly appreciate it if you would consult > with me so that you can: > > 1) Know what spec's that I am using (which happen to be > the *standard*) *A* standard, anyway; I've already appologized for blaming their brain damage on you. > 2) Know a little about my strategy and reasoning. > > before criticizing the work. Think database... If we need to extend the > code for sockets, I can do it in a day... Would you be adding an aio_recvmsg() to do it? I think that you can extend this argument to the point where you want an async version of any system call that could possibly block so you could use it for call-conversion based scheduling of N user space threads against M kernel space threads worth of quantum, where the N:M relationship is determined by how many processors you have and the number of processes you are competing against for quantum (ie: things like "give me quantum as if I were two processes"). Once the scheduler gives me a quantum, it's *my* quantum, and I should not be forced to give it away simply because I want to schedule some operation for which the resources aren't immediately available... It seems to me (still) as if the best way to achieve this would be an async call gate mechanism, where you get two flag bits in the sysent: #define SYSCALL_WONT_BLOCK 0x00000000 #define SYSCALL_MAY_BLOCK 0x00000200 #define SYSCALL_WILL_BLOCK 0x00000400 #define SYSCALL_BLOCK_MASK 0x00000600 For something that will block, you create an async context and return the context address as the call return value to user space immediately. For something that may block, you create the async context IFF you reach a blocking point, but delay returning it until you actually block, since you may not. For something that won't block, you return a special async contex after the call completes with completion status already signalled, and the return value present. This is all implementation detail, so I really don't care how it's actually physically implemented. You could leave of "will block" in favor of doing everything "may block", or in favor of creating a context and returning immediately on all potentially blocking ops (there are tiny wins to be had either way). The aio_* routines demanded by the lame-o POSIX "let's redefine the universe in an incompatible way each Tuesday, and while we're at it, let's ignore making the interface logically complete or correcting out past mistakes so you still need crap like libc_r" can be nothing more than wrappers. The real problem is "how do you avoid getting caught up in the POSIX vs. Microsoft War". POSIX has been a CLIN on many government contracts, which is why Microsoft was willing to wave their hands over the compatability issue once. But don't kid yourself that POSIX standards will be able to drive anything (other than "UNIX, into the ground") in the future. 8-(. Having a morose day... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712020621.XAA17318>