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 <firstname.lastname@example.org> 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.
> On Sat, Jan 25, 2014 at 12:20 AM, Jim Jagielski <email@example.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).
> I just couldn't think of an easy way to get around that
> except for having 1.5.1 break ABI.
> 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.
> On Jan 24, 2014, at 6:00 PM, Yann Ylavic <firstname.lastname@example.org> wrote:
> > 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 <email@example.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.