: I mean that they can be used separately, providing the same
: functionality, but their combination is rare, not because it can't be
: efficient, but because they represent different styles. Some programmers
: feel uncomfortably designing programs where they never can do things in
a
: "natural" order of actions performed on the same object, so they don't
use
: nonblocking I/O that can leave things incomplete and require doing
: something else at any moment. Others can accept that, but have problems
: with seeing multiple copies of themselves existing in one universe,
: trying to live independently of each other ;-), so they see
: "unnatural order" of nonblocking I/O operations as the lesser evil.
: Combination of two are never required to achieve the functionality, and
: mostly appear when the OS or libraries have significant bias toward one
of
: model, and programmer is biased toward another one. Performance
: requirements may change this, however I still don't believe in "threads
: will make everything faster", unless it has " on NT and Solaris"
: immediately following it.
: Of course, threads can be implemented through nonblocking I/O, and
it's
: possible to even implement nonblocking I/O through blocking one and
: multithreading, however the need of such tricks is more related to
: compatibility requirements than to anything else.
I'm not sure what you mean by threads on Linux, but on OS/2 (with which
I'm more familiar) different threads can be executing simultaneously on
different processors in an SMP environment. To my mind this is one of the
greater benefits of threads. Along with the notion of using a separate
thread to print (for example in wordprocessing software) and maybe
handling some http requests in a web server, and ftp request in an ftp
server.
Cheers
John Summerfield
http://os2.ami.com.au/os2/ for OS/2 support.
Configuration, networking, combined IBM ftpsites index.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu