Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 18151 invoked from network); 13 Jul 2006 16:12:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Jul 2006 16:12:54 -0000 Received: (qmail 69464 invoked by uid 500); 13 Jul 2006 16:12:50 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 69405 invoked by uid 500); 13 Jul 2006 16:12:50 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 69394 invoked by uid 99); 13 Jul 2006 16:12:50 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Jul 2006 09:12:50 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [209.133.199.10] (HELO jimsys.jagunet.com) (209.133.199.10) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Jul 2006 09:12:49 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by jimsys.jagunet.com (Postfix) with ESMTP id 4646F24294F for ; Thu, 13 Jul 2006 12:12:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <44B66CD5.5050508@gmail.com> References: <44B576AF.6080303@gmail.com> <44B579AA.1080205@turner.com> <5D8F9212-834B-4E18-AC7E-9A4008C634BD@jaguNET.com> <44B65285.8070901@turner.com> <44B66CD5.5050508@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <83BDA209-33F6-446D-94A1-B7A15A53652E@jaguNET.com> Content-Transfer-Encoding: 7bit From: Jim Jagielski Subject: Re: Additing a storage for the shared information of the worker in mod_proxy Date: Thu, 13 Jul 2006 12:12:28 -0400 To: dev@httpd.apache.org X-Mailer: Apple Mail (2.752.2) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Jul 13, 2006, at 11:55 AM, Jean-frederic Clere wrote: > With such an interface you assume only one process will access to > one slot... That is what the scoreboard allows. > Allowing updates from different proccesses on the same slot. > Should we have an ap_slot_read_look() and an ap_slot_unlock() for > that? Having some external (or even internal) process update a slot that isn't "its own" is dangerous. And the required locking would be slow. The scoreboard works as well as it does because we restrict write only to the owner of the slot.