Messages in this thread | | | Date | Sat, 23 Jan 1999 12:01:21 -0500 (EST) | From | "Mark H. Wood" <> | Subject | Re: User vs. Kernel (was: To be smug, or not to be smug, that is the |
| |
On Fri, 22 Jan 1999, Anthony Barbachan wrote:
> >> I guess I'm not sure what you mean by an interuppted system call then. > >> in what cases will a read for example get interupted? > >> I think I must be missing something (it's probably obvious, but I've > >> been staring at way too much windows code today). > > > >If your process gets a signal, read() will return -1 and set > >errno to EINTR. You must try the system call again, in a loop, > > > This does not happen on Linux, at least not when using Libc 5, without > undefining GNU or something like that. The GNU C library by default doesn't > interrupt the read or write call when the process receives a signal. Its a > nice feature, it allows me to leave out the error handling code that has to > take care of this problem on SunOS and others by restarting the same system > call; adjusted for any changes.
Very nice, but sadly nonportable. Sounds like we need an all-Unix conference to hash out an acceptable common solution, unless the majority really, really loves writing #ifdef s.
> >> That's why I said win32... most apps have to target 95/98/NT these > >> days, so using the native kernel API isn't practical (it also > > > >With this being the linux-kernel mailing list, the native kernel API > >is of interest. Win32 and POSIX can be done in user-space, as calls > >to whatever the kernel API is. > > > > > If I remember correctly this discussion started because someone wanted an > event-based (or something like that) API that would take care of the > "charging hords"(?) problem that occurs whenever select returns because data > is available, able to be written, etc and was monitoring multiple file > handles. If this were done in user space would that take care of the CPU > cycles semi-wasted and time lost looping through the file handles being > monitored? Wouldn't the API simply be hiding the select call. It appears
If you do it with select(), yes.
> to me that the only efficient way of implementing an event based API would > be if an assigned function in a user's program were called whenever data > became available for a particular file handle being monitored. For example
VMS calls these ASTs, and every I/O function that could block accepts one. This lets the application programmer definitively answer the question of what to do with this I/O completion, instead of making the kernel guess. It's a model I've come to appreciate, and if you'd rather be synchronous you can call the blocking version (functionW() rather than function() ) instead. But the price of this is that I/O had to be designed as fundamentally asynchronous, and a synchronizing mechanism had to be provided for the less-critical but more numerous cases where you want to block.
But this would require revamping much of the fundamentals of the I/O code, and the result would be so un-Unixy that I don't expect to see it in Linux anytime soon. Possibly the time would be better spent building a whole new kernel that doesn't attempt to be Unix-alike, and go off in a different direction.
> if a driver finished retrieving data from a device, in an efficient event > based model, it would then call whatever function in a user space program > was assigned to that event on that filehandle passing it the data so that it > can be processed immediately or semi-immediately (having the function > processed as soon as the process makes its way through the scheduler). And > for this implementation I do not see how you could implement this in user > space.
With ASTs you quickly learn to do as little as possible, like marking a buffer reusable or moving it to another linked list, and letting the main line do the heavy work. (I/O rundown gives the issuing process a priority boost, so setting a flag and waking the mainline code gives pretty good response, and if it's already running then there's no penalty.) Of course there are exceptions.
And you're right -- it requires at least some support from the kernel. Making sync. I/O appear to be async. is much more difficult in userspace than the other way 'round. It's a question of keeping decisions close to the information required to make them. The kernel knows best what the devices are doing, and the application knows best what *it* is doing with the results.
-- Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu Innovation is only valuable if it improves one's life; otherwise it's just one more silly change to cope with.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |