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.