apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Date Fri, 24 Jan 2014 23:41:21 GMT
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 <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).
> 
> 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.dev@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 <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.
>> 
> 


Mime
View raw message