lkml.org 
[lkml]   [1999]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectUser vs. Kernel (was: To be smug, or not to be smug, that is the question)
"Albert D. Cahalan" wrote:
> Henrik Olsen writes:
> > On Tue, 19 Jan 1999, Alain Williams wrote:
> >> On Mon, Jan 18, 1999 at 10:48:11PM -0800, Dan Kegel wrote:
> >>> "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.

> > This thundering herd "problem" can fairly easily be programmed around
> > without messing around with the select() semantics by letting everything
> > but one process wait on a semaphor instead of on the select, this ensures
> > only two proceses wake up, the one waiting on the select, and (shortly
> > after) the first one waiting on the semaphore once the first one releases
> > it. This is part of the way Apache gets around thundering herds.
> >
> > Of cause this can be seen as yet another hack to get around a problem in
> > the API,
>
> Yes, it is another gross and limited hack that makes the API hard
> to use and low-performance. Why should I need a semaphore?
>
> Windows apps mostly break because they depend on unsupported behavior.
> Perhaps some of the breakage is intentional - M$ must sell upgrades.
> Linux apps break this way too (remember init?), but not as badly because
> we don't have undocumented calls that apps commonly need.
actually, no... windows apps break because Microsoft has lots of "that
was a documentation error" or "we meant that API to behave in that broke
manner"
>
> If someone with great vision and design skills wants to create a
> new API for Linux, we should seriously consider such a proposal.
> Suggestions: immediate signals generated by code (SEGV, BUS...)
> should be converted to exceptions. (for C use _try, _throw, and
> _catch or let the app check as desired) Other signals should arrive
> as events. For every blocking call in the unixy API, provide a call
> to issue it in the background. Send a completion event when such
> calls are done. Multiple concurrent requests are good. Let the
> executable specify what event handlers may safely execute in
> parallel.

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? 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.

I still like the old principle, of if you can do it in user space, then
do it in user space.

Regards,
Steve

-
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    [W:0.149 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site