lkml.org 
[lkml]   [1999]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: User vs. Kernel (was: To be smug, or not to be smug, that is the
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [from the cache]
©2003-2011 Jasper Spaans