Of course, one could also say that anyone who uses internal APR implementation knowledge is doing something wrong...
And they would have a point. But it still begs the question what to do w/ slotmem which must set shmem permissions. I would guess what we should really do is provide apr_shmem_perms(). We could then have httpd 2.4 require APR 1.5.1 or later and let those who choose to use ftok know the risks. On Jan 24, 2014, at 6:20 PM, Jim Jagielski <j...@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). > > 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 <ylavic....@gmail.com> 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 <j...@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. >> >
