Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4AA1287F.2070308@rowe-clan.net>
Date: Fri, 04 Sep 2009 09:47:27 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: slotmem API notes
References: <C6C575CA.C5458%Brian.Akins@turner.com>
 <EAAF2AA2-9E3E-45D5-BA0F-FB6950845FF1@jaguNET.com>
In-Reply-To: <EAAF2AA2-9E3E-45D5-BA0F-FB6950845FF1@jaguNET.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Jim Jagielski wrote:
> 
> On Sep 3, 2009, at 1:31 PM, Akins, Brian wrote:
> 
>> On 9/3/09 10:30 AM, "Jim Jagielski" <jim@jaguNET.com> wrote:
>>
>>> But consider an independent process that wants to attach to that
>>> shared memory segment... at this point, we need a global lock that
>>> both Apache and this ind process will honor. So somehow we need to
>>> store that lock *in* the shared memory segment, so that all processes
>>> that attach to it can use it.
>>
>> Use a semaphore? The external process already has to know certain
>> things to
>> attach to the memory anyway.
> 
> Yeah, but this means that the external process needs to know that
> Apache is using a semaphore, or the name of the file that is being
> used for the mutex lock, etc... Something needs to be exposed, and
> we need some way of doing that...

Sounds like a process management and platform portability problem.

Note that on Win32 for example, where we have a single process, the
ideal mutex is a critical section.  But that isn't shared with or
accessible by other processes.

Of course there is the possibility that on some platforms, the shm
itself [or segments thereof] can be locked.  That would sure simplify
this part of the discussion.

>> Also, could just make external process use HTTP.
> 
> +1 But that really uglies up Apache, imo... basically we're using
> it as a mutex server. Talk about multi-protocol :)

No, not to serve the mutex?  That's nonsensical.  The slotmem should
just offer it's getter/setter to specific clients (e.g. localhost,
trusted local subnet boxes).  And if HTTP is the transport, where do
you come up with multi-protocol?  No different than some soap service
hosted through httpd.

The disadvantage is that if the resources are congested, an external
DoS would impact internal services as well.  In some cases, that might
even be the desired behavior, but in others it renders the slotmem
useless.

I'm wondering if we aren't spending way too many cycles describing
what memcached and other providers already provide more efficiently
than httpd could?