Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: User vs. Kernel (was: To be smug, or not to be smug, that is the | Date | Thu, 21 Jan 1999 12:36:03 -0500 (EST) |
| |
Steven Roberts writes: > "Albert D. Cahalan" wrote: >> Henrik Olsen writes: >>>>> "Albert D. Cahalan" <acahalan@cs.uml.edu> writes:
>>>>>> Blocking system calls were a bad idea. Signals were added to unix >>>>>> to address the lack of a general event queue. Since longjump won't >>>>>> get you out of one of those crummy blocking system calls, some >>>>>> fool made signals interrupt system calls. As a patch on top of >>>>>> a patch on top of a patch, app programmers need to wrap system >>>>>> calls in loops. Patching the brokenness even more, we see Netscape >>>>>> talking to itself to get around a stupid race condition. Since >>>>>> the unixy API does not support dispatching concurrent system calls, >>>>>> someone added the aio_* functions to "fix" it for the limited case >>>>>> of simple disk IO. All along the way people find hacks for their >>>>>> own immediate problem rather than fixing the API.
> I personally like blocking system calls. They fit in far better > for the application model I use. We have multiple threads, > and it is easier to block. We in fact don't use the non blocking > I/O calls in win32 because it is easier for us at least to use > blocking ones. Yes, async IO can be nice for certain things, but > saying blocking system calls are a bad idea is crap.
Don't tell me you _like_ interrupted system calls...
Threads change everything. How would you like a new thread whenever a signal arrives? That could be an alternate fix.
>> If someone with great vision and design skills wants to create a >> new API for Linux, we should seriously consider such a proposal.
> I think this kind of boils down to user vs. kernel API issues. > why not great this all new wonderful API set in a user space lib?
Ha, ha, ha. NO.
As a prototype, maybe. It would be an extraordinary kludge. It would have all the crappyness of user-space threads and worse.
> I really like that the > kernel API in linux is small compared to the kernel API in win32. I > quite a bit about the win32 API, but the most important thing I know, is > that it is a big ugly mess, and I don't think linux should head in that > direction.
No, the native NT kernel API is very simple. (it is not Win32)
> I still like the old principle, of if you can do it in user space, then > do it in user space.
How about "do it in the best place" instead? Often that place is a library, but don't get religious about it.
In this case, the kernel API itself could use some adjustments. Emulating that in userspace is a sick joke.
- 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/
| |