lkml.org 
[lkml]   [1999]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: To be smug, or not to be smug, that is the question

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.

>>> isn't up to the task. Sun had a modified select() back in
...
>> AIX select() allows you to wait on message queues as well as FDs.

These two and the pselect() that somebody mentioned ought to be
looked into. Maybe we are missing something useful.

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

> but changing a standard API is very definitely not the way to
> solve problems, that only deadends in something like the way Windows
> breaks applications left and right every time they "upgrade" the system.

Not at all. The old select() can remain as a depreciated feature for
standards compliance and backwards compatibility.

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.

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.


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