From owner-freebsd-chat Wed Jul 14 20:19:10 1999 Delivered-To: freebsd-chat@freebsd.org Received: from shell.webmaster.com (mail.webmaster.com [209.133.28.73]) by hub.freebsd.org (Postfix) with ESMTP id 8C386154CD for ; Wed, 14 Jul 1999 20:19:00 -0700 (PDT) (envelope-from davids@webmaster.com) Received: from whenever ([209.133.29.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Wed, 14 Jul 1999 20:17:59 -0700 From: "David Schwartz" To: "Tani Hosokawa" Cc: Subject: RE: Known MMAP() race conditions ... ? Date: Wed, 14 Jul 1999 20:17:59 -0700 Message-ID: <000301bece70$a40b5e20$021d85d1@youwant.to> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Wed, 14 Jul 1999, David Schwartz wrote: > > > > > > The current model is a hybrid thread/process model, with a number of > > > processes each with a large number of threads in each, each thread > > > processing one request. From what I've seen, 64 > threads/process is about > > > right. So, in one Apache daemon, you can expect to see >1000 threads, > > > running inside 10-20 processes. Does that count as a large number? > > Yes. And it's bad design. > > I'm curious. How would you do it? I would have a pool of threads and a job queue. Anything that can be done without blocking would be considered a job. When the server had jobs to do, it would queue them. The first 'free' thread would pull a job of the queue. If while processing a job I needed to block for any reason, I'd instead create a new job and set up to queue it when a particular network event occured. At least one special thread would call 'poll' for the set of jobs waiting for network I/O. When the network I/O could be completed without blocking, the special thread would move the job from the network queue to the active queue. When a thread became free, it would pull the head job off the active queue. If the active queue were empty, it would sleep waiting for a new job. The basic idea is that any time where you presently block on network I/O, you instead save your state and set it up so that when a 'poll' or 'select' that tells you that the network I/O can be completed without blocking, you pick up where you left off. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message