Messages in this thread | | | Date | Thu, 21 Jan 1999 08:29:20 -0800 | From | Steven Roberts <> | Subject | User 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/
| |