Date: Mon, 1 Dec 1997 02:46:22 -0700 (MST) From: Charles Mott <cmott@srv.net> To: chat@FreeBSD.ORG Cc: hackers@FreeBSD.ORG Subject: Re: ftp server on ftp.cdrom.com Message-ID: <Pine.BSF.3.96.971201023942.8138A-100000@darkstar.home> In-Reply-To: <199712010456.UAA00927@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971201023942.8138A-100000>