Hi --
The short version of this email is, please, can people review
this patch for server/request.c and see if it breaks anything?
There are versions for trunk and 2.2.x. Thanks in advance!
http://people.apache.org/~chrisd/patches/walk_cache/
I recently finished setting up mod_dav
Hi --
Thanks for taking an initial look at these patches; I reviewed
them a bit more as well and did some testing this morning which
resulted in a pair of small changes. One of those changes is important;
it catches the condition where the current walk finds additional
matches beyond those
Hi --
William A. Rowe, Jr. wrote:
It so happens I'm starting one of those cycles again right now with the
changes to the mis-handling of file matches that Nick(?) corrected in
trunk, and I'll study your patch in tandem. Thanks for your work!!!
Much appreciated, but alas, Justin pointed
Hi --
I've been spending a lot of time staring at mod_dbd and have
created four sequential patches for trunk:
http://people.apache.org/~chrisd/patches/mod_dbd_pools_groups/
I've tested each one in both the threads and no-threads cases,
making sure it compiles and runs with mod_authn_dbd.
Hi --
Chris Darroch wrote:
Much appreciated, but alas, Justin pointed out a serious conflict
in mod_authz_svn, and more generally, various modules may exist out
there that are also expecting authnz functions to be called for every
sub-request that has a different URI/filepath.
[snip
Justin Erenkrantz wrote:
Without looking at the code, I'd hope that means that they are version
1 providers. =) -- justin
Yes, that's what I used, although I wondered if that was ideal, or
whether it should be something like 0-initial-req-only ... but 1
seemed less ugly to me. :-)
Hi --
Paul Querna wrote:
- Rewrite the Core to be an Async Event state machine and data router.
- Break the 1:1 mapping of a worker to a single request.
- Change the meaning of MPMs. The problem with MPMs today is they are
really mostly platform abstractions -- not just abstractions of the
Nick Kew wrote:
Thanks. I've just reviewed both patches, and added them as an
attachment to PR#42327 and a proposal in STATUS.
I apologize for joining this thread a little late. I know it's
more complicated, but I'm inclined to suggest trying to bring the more
comprehensive trunk fixes
Bojan Smojver wrote:
If mod_dbd.c from trunk works in 2.2.x, we should just have that
instead. No need to carry two different things if the new stuff is
backward compatible.
If you need to, you can just drop the mod_dbd.c from trunk into
2.2.x; we do that and it works fine. The main
Nick Kew wrote:
I was wondering about that, but reluctant to propose a backport
from trunk without doing some more research. If you want to make it
a backport proposal, I'll try and get my brain around it (and one or
two related issues) in the morning.
The main thing I'd point to is this
Bojan Smojver wrote:
I apologize for joining this thread a little late. I know it's
more complicated, but I'm inclined to suggest trying to bring the more
comprehensive trunk fixes into 2.2.x.
Just a ping on the status of this backport...
The proposals are in the 2.2.x STATUS file,
Phil Endecott wrote:
http://marc.info/?l=apache-httpd-usersm=118765132424174w=2
My guess is that I'm encountering the known issues with DBD described here:
http://marc.info/?l=apache-httpd-devm=116742014418304w=2
Am I right in thinking that this is fixed in the trunk but not in
2.2.4?
Guenter Knauf wrote:
I think you would increase chance for another vote if there would be
only _one_ patch which applies cleanly against current 2.2.x head;
I've started testing with them, but got stopped since one patch didnt
apply of them all; therefore I only voted on the first one
Phil Endecott wrote:
OK; my experience seems to be that in this respect 2.2.4 has regressed
compared to 2.2.3 (though I may have been lucky in some way with my
2.2.3 setup) and certainly compared to 2.0.x + the 3rd-party
mod_auth_pgsql. I don't know if this affects how the issue is
Fred Woods wrote:
I've written an extension/hack for mod_dav. I would like to know if it
would be useful to others and how I might change it to be more portable?
The hack hooks the code to store, copy, rename, and remove files.
It creates a string representing the operation and the path
Hi --
A couple of months ago a short thread started in relation to the
PRs #16593 and #38034 (which also references #42987) on the various
problems related to ETags:
http://marc.info/?l=apache-httpd-devm=118831732512678w=2
http://issues.apache.org/bugzilla/show_bug.cgi?id=16593
Hi --
1) Per #38034, it appears that ap_meets_conditions() treats * incorrectly.
More precisely, I should say that ap_meets_conditions() isn't designed
to support the NULL resources of RFC 2518 (WebDAV). I'm certainly no
expert on these issues, so guidance is welcome.
RFC 2616 section
Henrik Nordstrom wrote:
On fre, 2007-10-12 at 00:25 -0400, Chris Darroch wrote:
RFC 2616 section 14.24 (and 14.26 is similar) says, If the request
would, without the If-Match header field, result in anything other than a
2xx or 412 status, then the If-Match header MUST be ignored. Thus
Nick Kew wrote:
My vote goes to r-notes.
Anything else relies on something with semantic significance that'll
risk breaking random things.
For the future (e.g. 2.4), we could review other options. For example,
abstract out r-finfo to a void* with an API for inspecting resources
Paritosh Shah wrote:
Thanks for the patches ... I'll take a look when I get some time.
I used resource-exists as the key instead of
NON_EXTANT_RESOURCE or NO_RESOURCE as suggested by Chris Darroch,
to avoid double negatives.
I wanted to use such a term because the default case, when
Paritosh Shah wrote:
There are really three states here ( wrt ap_meets_conditions())
1. resource exists
2. resource does not exist
3. nothing is known about existence of the resource
Currently ap_meets_conditions() does not make any assumptions about
existance of the resource ( case 3 ).
Hi --
Nick suggested I start posting more to the list, so this
one's on his head. :-) Per the guidelines, the patches themselves
are in Bugzilla in bug number 37533.
I'd also like to float the suggestion that the DBDKeep and DBDExptime
directives be renamed to match the use in mod_proxy,
Hi --
I updated my patch for #36090 for 2.2.0; dunno if anyone cares
to take a look. I've been applying this patch for some time, with
no apparent problems, FWIW.
One note about possible things for wiser minds to review, from
the tail end of the bug description:
The
Hi --
Well, this may be a sore point, but I'll tackle it anyway,
so apologies in advance. The fact that environment variables
created with SetEnv are applied during the fixups phase,
while SetEnvIf creates its variables during the post_read_request
and header_parser phases, does make my life
Hi --
I have a particular setup where what I'd like to do is reject all
requests that contain a particular HTTP header (in this case, a header
injected by hardware that means the request is coming from outside our
private network). Here's what I thought I could do:
SetEnv FOO 1
SetEnvIf
Hi --
This may be an old topic of conversation, in which case I apologize.
I Googled and searched marc.theaimslist.com and Apache Bugzilla but
didn't see anything, so here I am with a question.
In brief, on Linux, when doing an ungraceful stop of httpd, any
worker threads that are
Paul:
This may be an old topic of conversation, in which case I apologize.
I Googled and searched marc.theaimslist.com and Apache Bugzilla but
didn't see anything, so here I am with a question.
In brief, on Linux, when doing an ungraceful stop of httpd, any
worker threads that are
Hi --
Does anyone have any advice? Does this seem like a problem
to be addressed? I tried to think through how one could signal
the poll()ing worker threads with pthread_kill(), but it seems
to me that not only would you have to have a signal handler
in the worker threads (not hard),
Hi --
I've crafted what seems to me like a reasonably minimal set of
patches to deal with the issue I described in this thread:
http://marc.theaimsgroup.com/?l=apache-httpd-devm=113986864730305w=2
The crux of the problem is that on Linux, when using httpd with
the worker MPM (and probably
Hi --
Alexander Lazic wrote:
After 'make install' i started apache, then some seconds later i got the
message '...MaxClients reached...' but there was no entry in the access
log, and nobody have make a request to this server.
Jeff Trawick wrote:
There are problems accounting for child
Hi --
Someone tried to send me a fax in the middle of the night,
so I've been up for a while and I think I've realized there are
several subtle contention issues involved with any fix for this issue.
First of all, I should note that my initial patch in Bugzilla
has a flaw; it needs an else
Hi --
for (i = 0; i ap_threads_per_child; i++) {
if (status != SERVER_GRACEFUL status != SERVER_DEAD) {
ap_update_child_status_from_indexes(slot, i, SERVER_INIT, NULL);
}
}
[snip]
... after make_child() does its check for != GRACEFUL and != DEAD ...
After heading back
Colm:
The worker and event MPMs would use these to track their
non-worker threads; and the parent process for these MPMs could
monitor them as per option C to decide when the child process's
workers were ready to be counted.
+1, I think this could be very useful, I came accross the same
Jeff Trawick wrote:
On 5/1/06, Greg Ames [EMAIL PROTECTED] wrote:
after more thought, there is a simpler patch that should do the job. the
key to both of
these is how threads in SERVER_DEAD state with a pid in the scoreboard are
treated. this
means that p_i_s_m forked on a previous
Hi --
I've been working away on PR #39275 and in the process of thinking
about that and studying the scoreboard and the various MPMs, I've
turned up a few things. Rather than try to jam them all together
I've broken out the first set of them and thought I'd start mailing
them to the list.
Hi --
It looks to me like the memory allocated for ap_scoreboard_image
is a little bit over-sized. In r104404 the lb_score elements were
added to the scoreboard in the manner of the worker_score array,
and then in r105134 much of this was reversed, but the call to
calloc() still sizes
Hi --
This may not be necessary, but I notice that prefork and most of
the other MPMs set ap_my_generation to an initial value of zero.
The worker and event MPMs don't, though.
Chris.
=
---
Hi --
An older but essentially identical version of this patch is
in Bugzilla PR #38737.
Using the worker MPM (but not the event MPM), if Keep-Alives
are enabled and the timeout is reasonably long (e.g., 15 seconds),
then worker threads wait in poll() after handling a request
for any
Hi --
I don't suppose that anyone's had a chance to peek at this
big glob of a patch? I know it's rather a lot to digest. Advice
on whether such kinds of changes are desirable at all is welcome, too.
On reflection, I should probably have done the ap_swap_nodes()
refactoring in a separate
Hi --
Some time ago, I proposed this large patchset (better described,
I think, by the message referenced by the second link below):
http://marc.theaimsgroup.com/?l=apache-httpd-devm=114729206702495w=2
http://marc.theaimsgroup.com/?l=apache-httpd-devm=114788040600327w=2
Discussing the
Anton Golubev wrote:
It's the same, but I don't agree it is Virtual Host specific, as you
said.
This configuration (almost taken from documentation) also crashes the
server:
ServerRoot /usr/local/apache
Listen 80
User nobody
Group nobody
DocumentRoot /home/ivc2/public_html
DBDriver
Hi --
Some time ago, I proposed this large patchset (better described,
I think, by the message referenced by the second link below):
http://marc.theaimsgroup.com/?l=apache-httpd-devm=114729206702495w=2
http://marc.theaimsgroup.com/?l=apache-httpd-devm=114788040600327w=2
Discussing
Hi --
Some time ago, I proposed this large patchset (better described,
I think, by the message referenced by the second link below):
http://marc.theaimsgroup.com/?l=apache-httpd-devm=114729206702495w=2
http://marc.theaimsgroup.com/?l=apache-httpd-devm=114788040600327w=2
Discussing
Hi --
Well, as promised (threatened?), here are a complete set of patches,
I believe:
http://people.apache.org/~chrisd/patches/httpd_mpm_configs/
I did have one final (I hope) thought last night about this patch.
Currently the prefork, worker, and event MPMs hack their open_logs hook
Hi --
I noticed some recent activity in mod_dbd.c to deal with virtual
host configurations, but didn't pay a lot of attention, I confess.
Today I happened to upgrade a system from 2.2.2 to 2.2.3 and discovered
my AuthDBDUserRealmQuery directives now weren't getting inherited from
the main
Nick:
I don't think we ever had that kind of merge. And it also looks like
possible overspill/pollution, where directives from the main config
are not necessarily wanted in a vhost.
The complexity here seems to stem from two things. One is
specifically the treatment of prepared
Hi --
I was looking at (the amazing!) mod_rewrite.c in order to
figure out how it implements its passthrough mode, and in doing that
I looked at prefix_stat(), which is called in the opposite case,
when mod_rewrite is *not* passing a request along to other modules'
translate_name hook
Colm:
mod_dir insists on the indeces being regular files, which breaks with
mod_cache in a particularly nasty way. mod_cache doesn't fill out
rr-finfo for speed reasons, and because it's not always a file that the
cached entity is coming from.
The result is;
make request for /
to ignore the HTTP design.
This, if I understand correctly, is the subject of #42987. My
own best effort at understanding the issue, from my original post,
is below -- if you can weigh in with any clarifications or corrections,
that would be very helpful (to me, at least!)
Chris Darroch wrote
Michael Clark wrote:
I'm getting a segfault here in mod_dav from trunk (after a make clean)
running litmus using extras/httpd-dav.conf whereas it was working for me
last night. Not sure if this a work-in-progress. No time to file a bug
right now as i'm off for the weekend.
/* Set the
Hi --
This looks great! Some semi-random thoughts, dealing just with
the main header file.
I was a little puzzled by the name socache because I assumed
so meant shared object, like mod_so, until I read the code comments.
I wondered if it was true that people would only use this kind of
Hi --
With those thoughts in mind, some other possible names presented
themselves -- perhaps grouped under modules/foo, where foo is the
name of choice? I thought of map, dict, store, table, and hash,
possibly with a d (data, distributed) or s (shared) prefix, e.g.,
mod_dtable,
Graham Leggett wrote:
On a number of occasions recently I have run into the need to run some
kind of garbage collection within httpd, either in a dedicated process,
or a dedicated thread.
I've also written a few modules where each child process runs
a private thread in the background. I'd
Jim Jagielski wrote:
I'd prefer optimum runtime and let that drive how it gets exposed to
the admin, rather than the reverse... And then we can see if that
pain is worth it :)
+1 to this as a guiding principle.
I know our administrators would, above all else, like a standard
way to build
William A. Rowe, Jr. wrote:
I'd -1 a 2.4.0 release today, because nobody has even bothered to make
a candidate for 2.3-dev. Auth logic changes break most if not all third
party auth modules (broke an auth feature in mod_ftp). Not talking about
commercial modules but every third party
William A. Rowe, Jr. wrote:
I've been working with the 2.4 authn/z stuff a bit lately and
what I keep tripping over is that the default authorization merge rule
uses OR logic. For example, if I enable mod_access_compat and
put in a traditional:
I wonder if anyone would offer a fastfeather
Graham Leggett wrote:
A session is a simple table of key value pairs.
mod_session_dbd stores sessions within a SQL database. The session is
tracked by a cookie, very similar to a typical Tomcat session. The catch
is that you need a database beefy enough to handle the resulting load,
which
Brad Nicholes wrote:
So here was the thinking behind it when AuthzMergeRules was introduced.
Maybe there is still a bug here that needs to be addressed.
http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/[EMAIL PROTECTED]
Graham Leggett wrote:
Are there any special requirements necessary before mod_dbd will
successfully register a prepared statement?
You have to register statements to be prepared prior to the
post_config phase ... that's the main one I can think of. Does
that help?
Chris.
--
GPG Key ID:
[EMAIL PROTECTED] wrote:
Make it compile on pre-C99 compilers (Move decls to beginning of func)
Joe Orton wrote:
The ap_clear_auth_internal() definition doesn't match the way it's
called.
Thanks, both. Joe's checks in the past have taught me to use -Wall
religiously but apparently this
Graham Leggett wrote:
The session modules are all designed to go exclusively inside Directory
and Location sections, which allow you to precisely target which URL
space your session is valid for, and this can be repeated as many times
as you like creating as many individual sessions as you
Graham Leggett wrote:
Is that prior to or up to? If it's up to, it would help me a lot...
So long as you ensure you run before mod_dbd's hook in the post_config
phase, you should be able to register statements to be prepared (I think).
Once mod_dbd's post_config hook runs, it has an
Brad Nicholes wrote:
Directory /www/pages
Reject ip 127.0.0.1//Or any other Require directive
/Directory
Directory /www/pages/whatever
...
/Directory
Since the /www/pages/whatever directory did not specify any authz,
what should happen? If the AuthzMergeRules is OFF
Brad Nicholes wrote:
Your assumptions about how the 2.2 per-dir merging is correct.
Unfortunately the same concepts no longer apply to 2.4. The reason
why is this:
Directory /www/pages
SatisfyAll
Require ip 10.10.0.1
Require ldap-group sales
SatisfyOne
Require
Chris Darroch wrote:
Here's another thought: for people doing mass virtual hosting,
and who let their customers put authn/z directives into .htaccess
files with AllowOverride AuthConfig, I would think it may be
important to ensure that these rules still merge together in the
way they used
Graham Leggett wrote:
Let each consumer of authn providers redefine the list_provider_names
callback in case they are loaded individually without mod_authn_core.
Can you check if mod_auth_form also needs this?
Yes, it does -- looks like you're doing your own ap_lookup_provider()
calls on
Ruediger Pluem wrote:
Lets hope that we never decide to change anything to
authn_ap_list_provider_names. Otherwise I bet that we run into inconsistencies
which might be hard to track and lead to funny bug reports.
So I feel -0.5 on this.
Do you mean changing the function definition, or
Ruediger Pluem wrote:
The implementation of the function. IMHO it must be the same in all
modules. Otherwise it depends on the module load order what gets
called and done.
True -- an alternative might be to do the following:
- #define AUTHN/Z_PROVIDER_VERSION 0 in mod_auth.h
- change all
Ruediger Pluem wrote:
So we are using the optional function only because we do not have the defines
for AUTHN_PROVIDER_GROUP and the version number around in request.c. If they
would be around it would be quite fine to call ap_list_provider_names directly
from there, correct?
Yes, and in
Guenter Knauf wrote:
in order to simplify future configuration, and most important to
have same include path structure with both in-tree and installed
compilations I think it makes sense to move all mod_*.h headers with
public APIs to the common ./include folder.
+1 since it simplifies my
Brad Nicholes wrote:
I'm not real excited about adding a new authz directive. Authn and
authz are already very complex and adding a new directive to the mix will
just help to confuse people even more.
That's a good point. Mostly the idea of an Accept replacement for
Require came up as a
Brad Nicholes wrote:
This is where it starts to go wrong for me. Where it gets confusing
for somebody who is trying to figure out what the configuration
is doing is:
Directory /www/pages
SatisfyAll
Require ip 10.10.0.1
Require ldap-group sales
SatisfyOne
Brad Nicholes wrote:
I could go along with switching the default merging rule from OR to AND,
even within a dir block. The reason why it is OR today was basically
for backward compatibility. Since there really wasn't any kind of logic
before, OR was just the default. If we switch to AND as
Hi --
I wanted to get a little experience with the socache (small object
cache) providers which Joe Orton recently refactored out of mod_ssl
and so I've written a pair of modules, mod_shmap and mod_socache_zookeeper,
which are available here:
Brad Nicholes wrote:
So what I am really trying to say is that intra-block logic and
inter-block logic as far as merging goes, are tied together. If we
want to change the way that the logic of two block is merged, we
would also have to change the base state of each independent block.
It's all
Jim Jagielski wrote:
Add in r568323 and 568879. The approved patch
lacked updates to the doccos and so really shouldn't
have been approved as is, but what the heck, so I
went ahead and pulled the doccos changes from the orig
commit anyway. Also, since this is a userland change,
it should really
Brad Nicholes wrote:
I finally got around to making the switch so that the default merge
rule is AND rather than OR. However after making the switch, it
occurred to me that since the default rule is AND now, the
AuthzMergeRules default should remain ON. Otherwise the rule
inheritance won't
Eric Covener wrote:
Authorization in LDAP has a special path for when authentication
wasn't handled by mod_authnz_ldap, but r-user still may be mappable
to an DN on the LDAP server. Net, it can't do anything useful without
r-user. This short-circuit should be possible well before the
Dan Poirier wrote:
I like the idea of replacing ON with AND and OR. It would not
only provide more control, but make it explicit what kind of merging
was going to happen.
I have mixed thoughts about changing the default to OFF.
Cons: That would mean every container directive would have to
Eric Covener wrote:
I tend to prefer something closer to the old name, especially with the
Satisfy containers being optional. IOTW the sections here may not
be something explicit the user can look back to.
(Maybe IOW, in other words? :-)
They should be: since Directory and friends all
Ruediger Pluem wrote:
IMHO this requires a major bump (no problem on trunk) and not only a minor one.
Thanks for catching that and the missing apr_pcalloc() in mod_authz_core.c!
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Ruediger Pluem wrote:
could you please split such changes into atomic commits? One issue - one
commit. You also committed docs changes you didn't mention in the log
message.
I'm not sure if the crash fix shouldn't go into CHANGES.
Plus it makes it really hard to read the diffs if you mix
Dan Poirier wrote:
I'd find it much easier to understand if we had fewer directives, and
just built up the more complicated ideas by writing boolean expressions,
which most of us already know how to cope with.
Perhaps, and the underlying code should support a range of alternative
Hi --
I've been trying to get trunk to compile and run today, and
if I compile it without mod_unixd (and with the worker MPM) it compiles
and run, but then logs Server MUST relinquish startup privileges ...
and exits. If I try to compile mod_unixd, I get compile-time warnings
about conflicts
Ruediger Pluem wrote:
I was hoping that your patches would fix this, but sadly they did not.
Ironically, the problem appears to have little to do with authz,
but rather authn. The test httpd logs show it's failing to find
an htpasswd-type file in which to check the user's login and
Brad Nicholes wrote:
I haven't tried out the new authnz directives yet, but it at least
builds on NetWare.
Thanks -- glad to know it compiles, at least!
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Roy T. Fielding wrote:
IIRC, trunk contains (or contained) a security problem with regard to
backward compatibility with 2.x configs. I won't consider it releasable
until that has been fixed one way or another, and I can't tell from this
mail thread whether the actual fix was committed or not.
Hi --
Eric Covener wrote:
I had meant iif containers are used, I'd like their name to
communicate the require or reject part while the authz providers
would be match-like (because the Require on the inside is confusing
when surrounted by all the variations)
Yes, I thought that was a good
Joe Orton wrote:
* include/ap_socache.h: Use C++ safety wrappers, and rename -delete
to -remove since the former is a C++ reserved word.
Thanks again for the socache refactoring! I've been trying to
keep these two modules up-to-date with both the socache stuff and
Apache ZooKeeper
Roy T. Fielding wrote:
I totally understand the desire to make the implementation more
modular and to make a more sensible Satisfy logic, but I don't
understand the need for Match (as opposed to just extending Require)
and the odd changes in defaults (multiple Require defaults to
MatchAny
Hi --
As Paul Querna noted recently, some folks are using mod_fcgid
these days instead of mod_fastcgi, in part because it was (I believe)
the first of the two to work with httpd 2.2. Unfortunately, the
original developer of mod_fcgid, Pan Qingfeng, has largely moved on
to other things.
He
Hi --
This is all fairly simple, I think, especially if
MatchNotAny/RequireNone is removed as well so that Require retains its
apparent meaning everywhere. See if the patch below meets your
expectations; if so, I'll commit it and update the docs.
Sorry, here's a slightly updated one
William A. Rowe, Jr. wrote:
The mod_fastcgi implementation has the following terms;
Open Market permits you to use, copy, modify, distribute, and license
this Software and the Documentation solely for the purpose of
implementing the FastCGI specification defined by Open Market or
Hi --
I believe Pan Qingfeng (潘庆峰), the developer of mod_fcgid, has
joined this list for the time being while the possibility of mod_fcgid
becoming project in the Apache incubator is discussed. I'll use his
English name of Ryan Pan from here on.
I asked Ryan to join so that he could answer
Roy T. Fielding wrote:
I don't see a problem with RequireNone inverting the logic, and
I think it would actually be useful for blocking a set of bad
clients. Is it difficult to include that without MatchNotAny?
Not at all difficult; trivial, in fact. The only reason I took
it out as well
Joe Orton wrote:
Both modules look very neat! Are you going to commit them? I might
debate the naming of mod_shmap ;)
Heh, thanks. I don't know, I hadn't really thought about committing
them ... maybe the shmap one is more useful to other folks?
- have all providers consistently
Torsten Foertsch wrote:
the struct process_score in scoreboard.h contains a sb_type member. Can
anyone please explain what that item is for? I couldn't find any usage
in the code.
Looks like this was added back in r89115 along with a number of
other things which were (mostly) quickly
Joe Orton wrote:
mod_shmap would be useful at least in modules/test so I can write some
perl-framework tests for mod_socache!
OK, I'll think about doing that. The m4/dsp/NWGNU wizardry required
makes me tired just thinking about it, though. :-) In the meantime,
I think they compile again
Ruediger Pluem wrote:
Sorry, but I currently don't get the reason for moving the negate check down
in the code.
So far as I'm aware, there's no functional or even performance
difference at the moment (not that performance really matters here,
since this function runs at configuration time).
Ruediger Pluem wrote:
Not quite sure if this is really correct because apr_atomic_casptr
wants to have a (volatile void**) as first parameter.
That's what made me less than sure ... but my gcc 4.1.2 -Wall
definitely doesn't like that void** (dereferencing type-punned pointer ...).
I
1 - 100 of 192 matches
Mail list logo
