From owner-freebsd-questions@FreeBSD.ORG Tue Jan 25 03:21:02 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3285516A4F8 for ; Tue, 25 Jan 2005 03:21:02 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 0E6FD43D4C for ; Tue, 25 Jan 2005 03:21:01 +0000 (GMT) (envelope-from m@MHoerich.de) Received: (qmail invoked by alias); 25 Jan 2005 03:20:58 -0000 Received: from p508A52D7.dip.t-dialin.net (EHLO localhost) (80.138.82.215) by mail.gmx.net (mp011) with SMTP; 25 Jan 2005 04:20:58 +0100 X-Authenticated: #5114400 Date: Tue, 25 Jan 2005 04:20:56 +0100 From: Mario Hoerich To: Gert Cuykens Message-ID: <20050125032056.GA11198@Pandora.MHoerich.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: not organized X-Y-GMX-Trusted: 0 cc: freebsd-questions@freebsd.org Subject: Re: php and apache X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 03:21:02 -0000 # Gert Cuykens: > can somebody explain what the difference is between forks and > threads Nutshell version: fork(2) produces a new process, which may consist of multiple threads. fork(2)ing used to be slightly more expensive, as it creates a new process with an accompanying process control block (PCB) and allocates its own memory pages. Threads just use their processes' data segment and thus share pages. Which basically means one thread can trash another's data, whereas related processes can not. OTOH the time slices handed out by the process scheduler ("Hey! PID 384! Your turn for the next 20ms!") are further subdivided by the thread scheduler. Since both thread scheduler and context switches between threads produce some overhead (storing local data, instruction pointer and such) threads used to reduce the real CPU time a process could actually use for its algorithms. I said "used to", because this is basically the theory introductory textbooks on OS design will tell you.[1] There's plenty of ways to adapt costs, i.e. by making the process scheduler hand out larger slices to multithreaded processes or employing copy-on-write, which means that the parent processes' pages are just mapped into the child process, until the child actually writes to them. Traditionally, Unices had pretty cheap processes but rather expensive threads. (Windows, for example, had it the other way around). I didn't delve into this for quite a while, so sadly, I can't give you any details on the current state of things. HTH, Mario [1]: Be warned, this is from the top of my head and it's 4am in the morning with my bed waiting for me. I just hope I've been at least *somewhat* coherent... ;)