On Mon, 6 Mar 2000, James FitzGibbon wrote:
> > Some comments? Isn't so?
>
> In my experience, threads are the perfect way to speed up an I/O bound
> application. While one thread is blocked in iowait, others can be
> performing operations that do not contend for the same resource
> (calculation, I/O on some other resource like a socket, etc.)
Processes can do it better, and if i/o can be nonblocking, plain
poll()/select() loop can do even better (pathological cases of Java and
applications ported from Windows being the exception).
>
> This is of course implementation dependant; if you are using a user-land
> thread package like MIT pthreads, the kernel sees the entire process as one
> schedulable entity, so if one thread blocks on IO, all threads block.
Not really. What looks like blocking i/o for you can be nonblocking for
kernel if your threads support library translates it.
> If
> you are using a kernel-thread or hybrid implementation, the system scheduler
> allows the other threads to run as described above.
>
> FreeBSD's threading implementation in libc_r is (AFAIK) a hybrid model, and
> from personal experience I have found threaded applications under FreeBSD to
> be much easier to code for performance than their single-threaded
> counterparts.
My experience is the opposite -- if data structures are complex enough
to become a pain in the ass to lock, processes allow more simple design
than threads, and nonblocking i/o usually limits complex code to some
small piece of program that can be written/optimized/debugged once, then
left alone.
--
Alex
----------------------------------------------------------------------
Excellent.. now give users the option to cut your hair you hippie!
-- Anonymous Coward
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
