Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1865.1\))
Subject: Re: ftok (Was: Re: svn commit: r1561150 -
 /httpd/httpd/trunk/server/core.c)
From: Jim Jagielski <jim@jaguNET.com>
In-Reply-To: 
 <CAKQ1sVOBBrU7r7xA9Xc0nG4dkZeAtZQz-_S7xHPtL+wqpX5TWw@mail.gmail.com>
Date: Fri, 24 Jan 2014 18:50:50 -0500
Cc: httpd <dev@httpd.apache.org>,
 apr <dev@apr.apache.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <044453D1-31AE-4B6D-BC6A-9F7FFA6458F7@jaguNET.com>
References: <20140124202437.12DBC2388900@eris.apache.org>
 <CALK=YjOvUey2ckLWLa5C9F-5mf-aqihf9B=BvcCJ_E0+EZOShA@mail.gmail.com>
 <CAKUrXK4_P3yKm8ot305MsVjbPMFCh=LvNCa9EtzyZiG0vo-ENw@mail.gmail.com>
 <CALK=YjNn-u03_QB0+7yh=gifYkqjPHBTuRnhkZzT+fmVj7mA_g@mail.gmail.com>
 <D50FEF34-77B8-4DFE-AC32-9C53789FD000@jaguNET.com>
 <CAKQ1sVOM1W7W0soyGxmHBLwtneXMsqsQVtusDO-NXiT1HLJ8Yg@mail.gmail.com>
 <D575EDD7-2E16-4648-B0C4-836E72BD2AB1@jaguNET.com>
 <CAKQ1sVOBBrU7r7xA9Xc0nG4dkZeAtZQz-_S7xHPtL+wqpX5TWw@mail.gmail.com>
To: Yann Ylavic <ylavic.dev@gmail.com>

I think it could be debated on whether or not ftok(...,1) is
part of the ABI or not. The more I think about it,
it's not. But the fact that both slotmem and mod_fcgid, which
are *our* projects, "use" that knowledge, makes me wonder
who else makes that assumption.

What do others think...? It would be easy to make our
generation of a shmkey more robust by "breaking" that
agreement, and to handle slotmem we add apr_shm_perms()
to APR 1.5.1 and have httpd 2.4.8 require 1.5.1 or later...

Or we just consider it all a limitation of SysV based
shm and just keep things as is.

On Jan 24, 2014, at 6:40 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:

> Why couldn't APR document on using ftok(filename, =
filename[strlen(filename)-1]) for released versions, and do the right =
thing in trunk?
> Is ftok(filename, 1) part of the ABI since the change would break =
existing consumers?
> I can't see any solution if that's the case.
>=20
>=20
> On Sat, Jan 25, 2014 at 12:20 AM, Jim Jagielski <jim@jagunet.com> =
wrote:
> It's easy to generate something unique... the problem is that
> external APR users (such as mod_fcgid, etc) occasionally need
> to adjust the segment resources, and thus call ftok(...). Unless
> both APR *and* the users use the same proj_id, then they won't
> get the right segment (if at all).
>=20
> I just couldn't think of an easy way to get around that
> except for having 1.5.1 break ABI.
>=20
> What we need is apr_shm_ftok() that replaces ftok, both
> internally to unix/shmem.c as well as to users. We still
> would need to worry about versioning there as well since
> APR consumers would need to be aware if that function
> exists or not.
>=20
> On Jan 24, 2014, at 6:00 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
>=20
> > According to the man =
(http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html), =
ftok() uses only the low-order 8-bits of the id.
> > Maybe the APR could use the last char of the filename instead, so =
that the users knows and can choose it.
> > For APR's internal/choosen filenames (if any), this byte could be =
generated randomly.
> >
> >
> > On Fri, Jan 24, 2014 at 10:57 PM, Jim Jagielski <jim@jagunet.com> =
wrote:
> > On httpd there was a discussion regarding versioning, and
> > this got me thinking...
> >
> > Included in the APR 1.5.1 changes is an internal change
> > to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
> > calculates the key (via ftok())...
> >
> > The problem (see the Bugz report) was that using the constant
> > 1 would cause collisions, so I adjusted it to use a hash
> > of the filename. The problem there is that any external
> > APR users that needed to also determine the key needs to
> > be aware of that. And from what I can see, there is no
> > easy way to do that.
> >
> > So I will be pulling that from 2.0-dev and 1.5-dev until
> > we can figure out a better way. Ideas appreciated.
> >
>=20
>=20