From owner-freebsd-hackers Thu Nov 16 16:15: 7 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from shell.unixbox.com (shell.unixbox.com [207.211.45.65]) by hub.freebsd.org (Postfix) with ESMTP id 563E637B4C5 for ; Thu, 16 Nov 2000 16:15:04 -0800 (PST) Received: from localhost (fengyue@localhost) by shell.unixbox.com (8.11.0/8.11.0) with ESMTP id eAH0FSe19906; Thu, 16 Nov 2000 16:15:28 -0800 (PST) Date: Thu, 16 Nov 2000 16:15:28 -0800 (PST) From: FengYue X-Sender: fengyue@shell.unixbox.com To: Bakul Shah Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded tcp-server or non-blocking ? In-Reply-To: <200011162354.SAA07155@repulse.cnchost.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 Thu, 16 Nov 2000, Bakul Shah wrote: ->Yes, this is definitely simpler and preferable when servicing ->a small number of concurrent requests. But you have to spawn ->off as many processes as the worst case number of concurrent ->requests you want to service since while all the processes ->are busy servicing, additional connections are not being ->accepted (after the listen backlog is exhausted). By using Well, with some additional coding, the parent process could easily monitor how many child processes are being used at a given time (like using mmap() to create a shared memory region and have the child process increases the busy_count...etc) and then to decide if it needs to spawn off some more processes into the pool based on the percentpage of number_of_busy_processes/total_processes_in_the_pool. Just like the way apache does it I guess. And, ofcoz, I agree that there are some performance impact if too many processes blocking on the accept() call. But then again, we're just talking about an easy solution for a webserver that only wants to handle no more than 15 clients at any given time:) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message