Those who use ftok(, 1) externally like httpd will face the bug soon or later too (unless they use the same filenames each time). I think some (at least) will like this to be fixed, so the current code is fine for me.
On Sat, Jan 25, 2014 at 12:50 AM, Jim Jagielski <[email protected]> wrote: > 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 <[email protected]> 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 protected]> 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 <[email protected]> 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 protected]> > 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. > > > > > > > > >
