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