From owner-freebsd-hackers Mon Mar 6 6:43:12 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from phobos.illtel.denver.co.us (dsl-206.169.4.82.wenet.com [206.169.4.82]) by hub.freebsd.org (Postfix) with ESMTP id 82B4237B829 for ; Mon, 6 Mar 2000 06:43:03 -0800 (PST) (envelope-from abelits@phobos.illtel.denver.co.us) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.9.3/8.9.3) with ESMTP id GAA04399; Mon, 6 Mar 2000 06:43:06 -0800 Date: Mon, 6 Mar 2000 06:43:06 -0800 (PST) From: Alex Belits To: James FitzGibbon Cc: stefan parvu , Titus von Boxberg , freebsd-hackers@FreeBSD.ORG Subject: Re: Pthread blocking I/O In-Reply-To: <20000306092951.A76191@targetnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message