From owner-freebsd-hackers Mon Dec 1 01:47:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA24812 for hackers-outgoing; Mon, 1 Dec 1997 01:47:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA24803; Mon, 1 Dec 1997 01:47:02 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (tc-if2-35.ida.net [208.141.171.92]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id CAA14350; Mon, 1 Dec 1997 02:46:59 -0700 Date: Mon, 1 Dec 1997 02:46:22 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: chat@FreeBSD.ORG cc: hackers@FreeBSD.ORG Subject: Re: ftp server on ftp.cdrom.com In-Reply-To: <199712010456.UAA00927@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I implemented the limit using (believe it or not) system V shared memory. > The login class idea from wu-ftpd is escentially the same, but the > implementation in wu-ftpd doesn't scale and is very slow. Why is it slow? > Wu-ftpd maintains a file of all of the process IDs for a given class and > since this might become stale if an ftpd process should terminate unusually > or if the system crashes, it verifies each of the entries by doing a > kill(pid, 0) on them. On a machine like wcarchive, this means thousands of > kill()'s every time the limit for a class needs to be checked, which is at > least once for the login, and perhaps again if the current number is output > in the welcome message. Looking for a better way, I noticed one day that > system V shared memory keeps a count on the number of processes that have a > segment mapped, and further, the attach count is available via shmctl(). Aha. > So, I map ("attach") the appropriate shared memory segment into the process > (there is one per ftp login class). If the process exits for any reason, > normal or abnormal, the system unmaps the shared memory segment and thus > always keeps the attach count accurate. This provides a very low overhead > way of tracking the current number of users in each class without the need > of all of the PID files and verification. This is a really interesting way to do things. Question: is there anything unreliable about using waitpid() to see which processes have terminated? Charles Mott