On Fri, Jan 24, 2014 at 10:46 AM, j...@apache.org wrote:
Author: jim
Date: Fri Jan 24 15:46:47 2014
New Revision: 1561041
URL: http://svn.apache.org/r1561041
Log:
Merge r1561040 from trunk:
Using UDS, we sometime try ops not supported on UDS. Make this
a known (and therfore handable)
I could just check that APR_EOPNOTSUPP is defined ;)
In any case, yeah, I know... but not implemented isn't the
same as not supported, and so I'm not sure the best thing
to do here. So comments/suggestions are welcomed :)
On Jan 24, 2014, at 3:12 PM, Jeff Trawick traw...@gmail.com wrote:
On
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
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
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
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
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
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
On 25.01.2014 00:41, Jim Jagielski wrote:
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
On Sat, Jan 25, 2014 at 12:40 AM, Yann Ylavic ylavic@gmail.com wrote:
Why couldn't APR document on using ftok(filename,
filename[strlen(filename)-1]) for released versions, and do the right thing
in trunk?
ftok(filename, hash(filename)) is much better of course, I misread
external as
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 j...@jagunet.com wrote:
I
OK... how about this:
1. We fix the FIXME in unix/shm.c which sez that the
shm permission should be 0600. We instead set
it to 0644 ala the rest of the shared-mem permissions
instead of the super-permissive perms we use now
(for SysV shm). [1]
2. We re-add the robustness fix for
12 matches
Mail list logo
