Date: Thu, 16 Nov 2000 15:54:47 -0800 From: Bakul Shah <bakul@bitblocks.com> To: FengYue <fengyue@bluerose.windmoon.nu> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded tcp-server or non-blocking ? Message-ID: <200011162354.SAA07155@repulse.cnchost.com> In-Reply-To: Your message of "Thu, 16 Nov 2000 15:20:29 PST." <Pine.BSF.4.21.0011161515560.18678-100000@shell.unixbox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> why not just bind to the port and then spawn off some processes (like 20 > in his case) to do the accept(), once the accept() returns successfully just > take care of the request, close the connection and then goes back > to accept(). Simple, easy, and even scales pretty well. Since > it's freebsd, you even don't need to worry about putting a lock > around the accept() call. 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 one process to accept connections, hand out requests and create processes as needed and by allowing idle processes to exit, you can dynamically adjust the number of server processes (e.g. depending on some user input or system load or resource use or day of time or whatever). You can also reject additional requests more intelligently (or redirecting them elsewhere) as opposed to not just accepting new connections. So this is more flexible at a small increase in complexity. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011162354.SAA07155>