From owner-freebsd-bugs Thu Aug 7 08:30:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA12779 for bugs-outgoing; Thu, 7 Aug 1997 08:30:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA12763; Thu, 7 Aug 1997 08:30:01 -0700 (PDT) Date: Thu, 7 Aug 1997 08:30:01 -0700 (PDT) Message-Id: <199708071530.IAA12763@hub.freebsd.org> To: freebsd-bugs Cc: From: Marc Slemko Subject: Re: kern/4243: file locking doesn't work for pipe Reply-To: Marc Slemko Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR kern/4243; it has been noted by GNATS. From: Marc Slemko To: David Greenman Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/4243: file locking doesn't work for pipe Date: Thu, 7 Aug 1997 05:22:34 -0600 (MDT) On Thu, 7 Aug 1997, David Greenman wrote: > Hmmm. Maybe I'm missing something obvious, but I can't think of a reason > why one would want to do file locking on a pipe (which is not a shared > resource). This sounds like a bug in Apache to me... The specific reason why it is done in this case is as follows: - it is possible to use a program to rewrite URLs using mod_rewrite in Apache. - when that is done, the implementation creates one process to do the rewrite before the child processes are forked. Each child has access to the input and output descriptors of the one process. - when a child wants to use the program for a rewrite map, it has to be sure it has exclusive access. There are a lot of ways to solve the above problem and many other ways to implement a solution. This particular one locks the descriptor to ensure only one child accesses the program at a time. -- Marc Slemko | Apache team member marcs@znep.com | marc@apache.org