> Date: Tue, 12 Jan 1999 15:00:38 -0500
> From: Benjamin Scherrey <scherrey@gte.net>
> Reply-To: scherrey@proteus-tech.com
> To: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-kernel@vger.rutgers.edu
> Subject: Re: Kernel Threads: Dr. Russinovich's response
>
> I'm also curious as to whether or not his criticisms about signal handling
> are correct. Linux became a usable development environment for me when kernel
> threads were finally introduced. I thought the implementation model was novel
> and was initially concerned about the idea but found that my application code
> seemed to perform pretty well with it (as compared to WindowsNT (Linux was much
> faster) on i86 and Solaris (Linux compared well and depends on the app) on
> SPARC) so I've not paid too much attention about the details nor have I used any
> "Linux-specific" features of its threading model. I will be doing some
> multi-cpu, thread intensive, real-time development under Linux over the next
> couple of months and this issue could impact me if true.
the concern may not be with performance of either the thread or signal
implementations alone, but in how they can be combined usefully by
application developers.
we all appreciate that Linux is an attempt to implement the POSIX
standards. however, as many respondants on this list can attest,
sometimes the standards don't make sense, or are contradictory or vague.
there are lots of large gray areas in the standard and implementation of
both signals and threads that may make it um, challenging to use a
signals-based implementation of async I/O in a threaded application. many
feel that this model is unecessarily complicated, and some even believe it
is completely unworkable. yes, async I/O can be had as a side-effect of
real-time signals. but is that really the preferred way to have async
I/O?
what's more, i don't believe we really want pure async I/O in our
applications. the kernel already handles asynchronicity -- why ask
applications to reinvent the wheel? the kernel should provide a useful,
performant, and clean abstraction to applications so that they can worry
about reliably and efficiently completing their specific task.
i think that one area where people neglect to see the architectural
significance of completion ports is that they simplify an application's
design not only by providing queued I/O, but also by creating a clean way
of dispatching work efficiently to multiple threads. this is what
select() has done in the past, but select() isn't workable any more.
- Chuck Lever
-- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>
- 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/