apping)
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Index: scoreboard.c
===
RCS file: /home/cvs/httpd-2.0/server/scoreboard.c,v
retrieving revision 1.60
diff -u -d -r1.60 scoreboard.c
--- scoreboard.c27 Feb 2002 04
On Fri, 1 Mar 2002, Cliff Woolley wrote:
> Does this look right? (attached to avoid line wrapping)
Hmm, no, it doesn't. :-/ Scratch that. Back to the drawing board.
--Cliff
--
Cliff Woolley
[EMAIL P
his
pointer... did I miss one?
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Sat, 2 Mar 2002, Brian Pane wrote:
> apr_bucket_heap and ap_bucket_error, I think
Hmmm.. I'll go check it out. Thanks for the review. :)
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
because I tried it once).
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
, that's the reason logging remained in
Apache and didn't go into APR.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ist of Perl modules (wow), then
something more centralized perhaps. :)
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ms) 8KB boundary. Either way's fine with me.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ing on it and get back to you asap.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
til APR 1.0 is finalized.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
no. Our naming
convention is that the function is named after the apr_foo_t type it
operates on, not what header file it's in. apr_socket_set_inherit
operates on an apr_socket_t, so the name is correct.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
r can move on ;)
>
> +1. -- justin
+1
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
c) (apr_c_is_fnchar[(unsigned char)(c)] & 2 == 2)
> +#define IS_SHCHAR(c) ((apr_c_is_fnchar[(unsigned char)(c)] & 2) == 2)
It *is* necessary... == has a higher precedence than & does. Good catch.
--Cliff
------
Here's a heavier-weight but pool-free and potentially faster alternative
to Brian's proposal for your benchmarking enjoyment :)
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
? config.nice-prefork
? c
a pointer to the allocator
before we call apr_allocator_free() so that we will still have a valid
pointer to pass to apr_allocator_destroy() afterward. Attached is a
revised patch.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
the same configuration as a
baseline?
Thanks!
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
be reversed. But word on the street is that
that causes problems elsewhere. I haven't personally had time to look
into it, but I can imagine that it could get pretty ugly in some places...
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
chunks, and then it
worked. Ridiculous.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
test/testlockperf.c
./srclib/apr/test/testprocmutex.c
./srclib/apr/test/testthread.c
./srclib/apr/test/testatomic.c
./srclib/apr/test/testglobalmutex.c
./srclib/apr/exports.c
./srclib/apr/atomic/unix/apr_atomic.c
./srclib/apr/atomic/netware/apr_atomic.c
--------
. thanks Brian! I need to remind myself to compile
without APR_HAS_MMAP once in a while to check fo this kind of thing. :(
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
+if (mm->is_owner && ((rv = mmap_cleanup(mm)) == APR_SUCCESS)) {
apr_pool_cleanup_kill(mm->cntxt, mm, mmap_cleanup);
return APR_SUCCESS;
}
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
think of an easy solution for this one.
Granted, it's not killer like the problem above, just suboptimal.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ed access to the cleanup function itself, but it's static
to apr/mmap/*/mmap.c.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
e results of the subrequest
were not setaside into r->main's pool? Could that explain any of this?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ssumptions based on our knowledge of how pool cleanups
work internally, but especially with the changes proposed for
apr_allocator_* to have a freelist size limit and so forth, we could get
ourselves into trouble easily with a feature like this.
--Cliff
--
On Wed, 17 Apr 2002, Dave Hill wrote:
> My first inclination was to think "what a bonehead thing to do", my
> second inclination was that maybe apr should protect me from myself a
> bit more
...
> -or-
> Wouldn't it make sense for me just to check my arguments be for calling
> apr :-)
APR typ
bly preferable. You'll most likely want to hang onto that return
code, though, like this:
while ((rc = apr_file_read(file, buffer, &len)) != APR_SUCCESS)
{
...
}
--Cliff
------
On Thu, 18 Apr 2002, Joe Orton wrote:
> Sure - I'd just hope the change could be made for the time being, until
> someone gets round to that, since currently APR won't build on
> combinations of modern glibc/kernel.
Which combinations? It works fine for me on glibc 2.2.5 / linux 2.4.18.
Granted,
On Thu, 18 Apr 2002, Justin Erenkrantz wrote:
> I committed this second part as with that testatomic passes here
> on my Linux/SMP box.
It passed for me beforehand on my non-SMP linux box, but it still passes
afterward, so +1 on that commit.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
g overwritten when using buildconf (but it doesn't for me).
That's my guess as well.
> Or, you still haven't resolved the conflict created when I added
> the config.{guess|sub} to the repository. -- justin
Nope, did it.
Thanks,
Cliff
--------
On Fri, 19 Apr 2002, Justin Erenkrantz wrote:
> I also tweaked expat's buildconf.sh to match APR's invocation of
> libtoolize so that it shouldn't update with local copies. -- justin
Thanks!
------
Cliff Woolle
able-atomic.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
nge committed. Thanks!
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
dist and create a
> libapr.tar.gz package, similar to the libapreq.tar.gz stuff I see on the
> ftp site?
For now you can download snapshot tarballs. A release tarball will be
available when APR reaches 1.0 (which probably isn't that many months
off).
--Cliff
---------
1.0 release.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Why do the apr_dbm_*_ex() calls use strings instead of symbolic constants
to select a dbm type?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Ouch... the API docs on apr.apache.org are way out of date. How do I
update them?
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
perf.org
does
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
exit(1);
> }
> pattern_zero = apr_strmatch_precompile(pool, "", 0);
> if (!pattern) {
> printf("FAILED\n");
> exit(1);
> }
Cut-and-pastos on the if conditionals, I assume?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
r if we can *make* it so they don't (which of course we
could ;), I'd be very +1 for getting rid of the macro. Somebody on Win32
will probably come up with a good reason though. But if that's the case,
why don't we use the thing?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
nitialize can_mmap in apr_bucket_file_make(), preferably to
true.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On 11 May 2002 [EMAIL PROTECTED] wrote:
> +f->can_mmap = 1;
Great, thanks!
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
hat
check_brigade_flush() has been burned at the stake), though.
So the real question is this: is it ever possible for strlen()+memcpy() to
be faster than the while loop used here? I believe the answer is no.
+0 on the optimization.
--Cliff
-----
plexity to the codebase every time we
> want another 1% improvement. We'll end up with an unmaintainable codebase;
> it'll run wicked fast, but we won't be able to fix or improve it.
A point... and the reason I said +0 and not +1.
--Cliff
----
quot;$@"
[EMAIL PROTECTED]:/root/apache/php4# make >/dev/null
...
make: *** No rule to make target `main/internal_functions.c', needed by
`main/internal_functions.lo'. Stop.
main/internal_functions.c was never generated. Now at least it would get
built by the Makefile if it *did* exist, which is more than used to
happen.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Fri, 17 May 2002 [EMAIL PROTECTED] wrote:
> There is a:
>
> #define APR_WANT_MEMFUNC
>
> This seems to interact with the above; i.e. when you do not get apr_pools
> in early enough. Is this avoidable; can we warn for this ?
I'm not sure I understand what the problem is. Is there a part
t want people
to use.
We've already bumped the MMN for Apache 2.0.37... can we just call that
good enough and note this as a change that must be made? It's a simple
search and replace.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Fri, 17 May 2002, Justin Erenkrantz wrote:
> No, there isn't any OS-specific code in the LDAP section, so the code we
> have is inherently portable. It's only related to how we deal with the
> different LDAP libraries that are available. For rationale, I see the
> DBMs as the proper predecent.
add (or subtract, one of the two), and that it was
in the Win32-specific time code.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Tue, 21 May 2002, Cliff Woolley wrote:
> Didn't someone post a patch for this months ago? I remember it was an
> extraneous timezone add (or subtract, one of the two), and that it was
> in the Win32-specific time code.
Was this it, perhaps?
On Tue, 21 May 2002, Cliff Woolley wrote:
> Index: time.c
> ===
> RCS file: /home/cvs/apr/time/win32/time.c,v
> retrieving revision 1.32
> diff -u -d -r1.32 time.c
> --- time.c 15 Apr 2002 00:01:09 -
7;s not.
void apr_thread_yield()
{
}
Oh joy.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
f test -r "/dev/random"; then
+AC_DEFINE(DEV_RANDOM, [/dev/random])
+AC_MSG_RESULT(/dev/random)
rand="1"
else
case $host in
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
alty to *those* formats, as long as it can be done
without impacting the performance of the other, more heavily-used formats
in a horrendous way.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
way to do it. If you'd rather I
expanded the macros out, I can... it's only three lines per if-block.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
). I *thought* I was very careful to keep the
exact semantics, but I might have missed this case. I'll take another
look at it.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Thu, 23 May 2002, Cliff Woolley wrote:
> > At some point, apr_brigade_write() got broken. When the HEAP bucket at the
> > end of the brigade fills up, the flush function should be called. The
> > current code allocates *another* heap bucket. With this logic, it is
>
fe ""
shift = (int *) 0x8111d00
s_next = 0x8161df7 ")"
p_start = 0x8111ce0 "Mozilla/2"
p_end = 0x8111ce8 "2"
I'll look into this a bit more and report back in a while.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Thu, 23 May 2002, Cliff Woolley wrote:
> (gdb) bt
> #0 match_boyer_moore_horspool (this_pattern=0x8111cf0,
> s=0x8161dc4 "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; )",
> slen=58) at apr_strmatch.c:133
> #1 0x806a616 in match_headers (r=0x8161048) at mo
On Thu, 23 May 2002, Cliff Woolley wrote:
> > #0 match_boyer_moore_horspool (this_pattern=0x8111cf0,
> > s=0x8161dc4 "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; )",
> > slen=58) at apr_strmatch.c:133
>
> (Note that -71 is a non-printable superscr
On 24 May 2002, Jeff Trawick wrote:
> > Unfortunately we can't just pstrdup because we have no pool to dup into.
>
> +1
>
> The API needs to be changed to use const char * if at all possible.
> This isn't the first time this has come up.
Already did that along with my commit yesterday. :)
--Cli
On Wed, 22 May 2002, Aaron Bannert wrote:
> On Wed, May 22, 2002 at 08:24:04PM -0700, Justin Erenkrantz wrote:
> > IIRC, /dev/random is a "better" source of entropy than /dev/urandom
> > because /dev/random can block waiting for good enough bits gathered
> > from the system while /dev/urandom must
On Sun, 26 May 2002, Ben Laurie wrote:
> >>3) open /dev/random in non-blocking mode and defer EAGAIN reads
> >> until later (read it at startup; if it would block, try again when
> >> the entropy is actually needed, failing if it isn't ready by then
> >> -- no idea if this would even work)
On Sun, 26 May 2002, Ben Laurie wrote:
> > What about a --with-devrandom= option for people who do want to go
> > the /dev/urandom route?
I'm starting to prefer this option I think.
> Surely its configurable anyway? Changing the default strikes me as
> something that will bite you if you aren't
On Mon, 27 May 2002, Ben Laurie wrote:
> Hmmm. Well, IMO it should be configurable at runtime, especially since
> some other OSes have yet more sources of entropy (/dev/arandom for
> example).
Oh good, that matches the patch I've been working on. I'll post it in a
little while. PS: is /dev/aran
On 28 May 2002 [EMAIL PROTECTED] wrote:
> jwoolley02/05/28 16:15:10
>
> Modified:.CHANGES configure.in
> Log:
> Added --with-devrandom=[DEV] configure flag which allows a particular
> "/dev/random"-compatible device to be specified, overriding the
> default search path (/
Oops, I missed one thing:
On Tue, 28 May 2002, Cliff Woolley wrote:
> 1) If --with-egd= is specified, --without-devrandom is assumed
>and the EGD socket is used as the source of entropy.
>
> 2) Otherwise, if --with-devrandom= is specified with a particular
>device, that
On Wed, 29 May 2002, Sander Striker wrote:
> > While we're at it, apr_allocator_alloc and apr_allocator_free are also
> > defined inline. I don't think that makes much sense, given the size of
> > those functions.
>
> Hmm, so windows isn't smart enough to do both inlining and exporting?
> I'd like
On 31 May 2002 [EMAIL PROTECTED] wrote:
> rbb 2002/05/31 13:51:20
>
> Modified:buckets apr_buckets_eos.c apr_buckets_file.c
> apr_buckets_flush.c apr_buckets_heap.c
> apr_buckets_mmap.c apr_buckets_pipe.c
> apr_
On Fri, 31 May 2002, Ryan Bloom wrote:
> I considered that, but I am actually thinking of the future, where there
> are different types of data. For example, when we want to send the
> headers down the filter stack as a part of the brigade, that is metadata
> and should be marked as such. Howeve
On Fri, 31 May 2002, Ryan Bloom wrote:
> Length does always mean data, but length has nothing to do with this
> discussion.
Just to update everybody else, we just had a big smackdown discussion
about this on IRC. We had to cut it short for various reasons, though.
We'll pick it back up later ton
On Sun, 2 Jun 2002, Ryan Bloom wrote:
> > +enum {
> > +/** This bucket type represents actual data to send to the
> client. */
> > +APR_BUCKET_DATA = 0,
> > +/** This bucket type represents metadata. */
> > +APR_BUCKET_METADATA = 1
> > +} is_meta
On Mon, 3 Jun 2002, Paul Marculescu wrote:
> I made a little patch for apr-util's apr_uri.c to handle win32 absolute
> paths under file:// schema.
I'll admit it strikes me as a bit odd to be supporting platform-specific
forms of _uniform_ resource identifiers. :-) Is this a
standards-recognized
On Mon, 3 Jun 2002, Paul Marculescu wrote:
> > PS: Please be sure to follow our styleguide when submitting patches...
> > namely, no tabs. :)
>
> There were some tabs in the apr_uri.c as I "cvs co" it a few minutes ago
> (again, to make sure).
>
> so I got a little confused. Anyway, I'll keep tha
On Sun, 2 Jun 2002, Ryan Bloom wrote:
> This field can only have two values, DATA or METADATA. ... If this is an
> integer, then anybody can extend it simply by choosing another int
> value.
The field can still have whatever values anybody wants. It's just that
only two of them have names.
--Cl
On Mon, 3 Jun 2002, William A. Rowe, Jr. wrote:
> Would it make sense to introduce APR_FILE_PIPECHECK to ask
> apr_os_file_put() to first check an apr_file_info_get() of the handle, and
> set the flags correctly if this is a pipe device (e.g. pass this flag for
> apr_file_open_stdin/out/err when t
[Moved here from [EMAIL PROTECTED]
On Thu, 6 Jun 2002, Justin Erenkrantz wrote:
> On Thu, Jun 06, 2002 at 04:51:10PM -0700, Aaron Bannert wrote:
> > I'd *love* to see progress on something like this, but whenver I start
> > thinking about this kind of a MPM I run into the problem where brigades
On Mon, 10 Jun 2002, Pier Fumagalli wrote:
> Now, the question is _why_ that thing is called and why libsvn_ra_local.so
> does not exist (if shared is disabled, it should be compiled in, right?)...
I was under the impression that it was one of those things of SVN
attempting to load all extensions
On Mon, 10 Jun 2002, Roy T. Fielding wrote:
> I know of one existing bug in httpd that I would consider a
> showstopper, if I were RM, due to the way APR handles time.
Are you going to tell me what it is? :)
On Mon, 10 Jun 2002, Aaron Bannert wrote:
> On Mon, Jun 10, 2002 at 03:57:29PM -0700, Justin Erenkrantz wrote:
> > How about using the value we already have:
> >
> > typedef apr_int32_t apr_short_interval_time_t;
>
> Unfortunately, that type still has units of milliseconds.
> Seems like Roy needs
On Tue, 11 Jun 2002, William A. Rowe, Jr. wrote:
> However, we aught to define convenience macros;
> #define APR_BUSEC_PER_SEC 1048576
I was thinking the same thing. +1.
--Cliff
On Wed, 12 Jun 2002, Miguel Camargo wrote:
> I am trying to modify the APR library just to add some specific features
> in it and use it in Apache.
What kinds of things, just out of curiosity?
> But i have some doubts about the meaning and the differences among the
> macro definitions of:
The f
On Wed, 12 Jun 2002, Cliff Woolley wrote:
> There are a *few* cases where we use HAVE where we should be using HAS,
> and those ought to be cleaned up. But we're mostly consistent. :)
Responding to this message caused me to take a second and actually go look
at how consistently
On 12 Jun 2002 [EMAIL PROTECTED] wrote:
> +#define APR_TIME_USEC(time) ((apr_int32_t)(time) % APR_USEC_PER_SEC)
> +
> +#define APR_TIME_SEC(time) ((apr_int64_t)(time) / APR_USEC_PER_SEC)
> +
> +#define APR_TIME_FROM_SEC(sec) ((apr_time_t)(sec) * APR_USEC_PER_SEC)
> +
> +#define APR_T
On Wed, 12 Jun 2002, Miguel Camargo wrote:
> First of all,thank you Cliff and Ryan for your answers!
No problem. :)
> ../apr/include/arch/unix/fileio.h:
>
> at the begining:
>
> #if APR_HAVE_NEWFEATURE_H
> #include
> #endif
Right.
> APR code...
>
> #if APR_HAS_NEWFEATURE ? /* or also APR_HAV
On Wed, 12 Jun 2002, William A. Rowe, Jr. wrote:
> It seems that we've decided sometime back that all macro-fns should be
> declared in ucase. Now, we can debate that issue again, but if someone
> could pull up a reference to that thread in the archives it would be
> most cool.
Somewhere in [EMA
On Wed, 12 Jun 2002, William A. Rowe, Jr. wrote:
> time [(apr_time_t]] Enter
> APR_USEC_PER_SEC [(apr_time_t)100] Enter
Ah. I missed the fact that APR_USEC_PER_SEC has a built-in cast.
Nevermind.
--Cliff
On Sun, 16 Jun 2002 itojun@iijlab.net wrote:
> on unix platforms, apr shipped with httpd 2.0.36 asks for truely-
> random number (/dev/random) instead of so-so random number
> (/dev/urandom). question: is it really necessary to require
> /dev/random instead of /dev/urandom
On Mon, 17 Jun 2002, hiroyuki hanai wrote:
> Ben Laurie wrote:
> > > you can specify with a ./configure argument which one you want. It will
> > > be part of 2.0.38.
> >
> > I still say it should be runtime configurable.
>
> I strongly agree with Ben.
Well, so do I. But somebody's got to sit do
Huh, that's odd. I swear I tested this. I'll look into it tomorrow and
place this in patches/apply_to_2.0.39/ if need be.
Thanks,
Cliff
On Wed, 19 Jun 2002 itojun@iijlab.net wrote:
> regarding to random number device in apr - thanks for
> --with-randomdev=foo configure option in
On Tue, 18 Jun 2002, it was written:
> the attached patch may not be correct. sorry.
Well, just keep me posted.
Thx,
Cliff
On 27 Jun 2002, Jeff Trawick wrote:
> So I guess sizeof(long) is 8 bytes on 64-bit HP-UX? sizeof(long) is
> still 4 on 64-bit AIX.
$ uname -a
HP-UX nova126 B.11.00 U 9000/785 2010844465 unlimited-user license
$ cat test.c
#include
int main()
{
printf("%d\n",size
[[ None of my emails from this evening seem to have actually gone out
(misconfig on my end, I think), so here's this again. Sorry if it's
a dupe. ]]
-- Forwarded message --
Date: Fri, 28 Jun 2002 02:50:06 -0400 (EDT)
From: Cliff Woolley <[EMAIL PROTEC
On 28 Jun 2002, Jeff Trawick wrote:
> The first fun comes during buildconf processing:
>
> $ ./buildconf
> buildconf: checking installation...
> buildconf: autoconf version 2.53 (ok)
> buildconf: libtool version 1.3.4 (ok)
> Copying libtool helper files ...
> Creating include/arch/unix/apr_private
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
> I have one bit that must be broken before 1.0, and cannot be remedied easily.
> I'd like to simply break these things before Apache 2.0.40 is tagged.
+1 on all counts. 2.0.40 will already require a full recompile anyway.
Other users of APR must
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
> If Cliff wants to commit the semantic change to apr_table_[v]do, I'll
> +1 here and raise you a _NONSTD correction. Along with Sander's
> changes to make the unsafe transparent apr_allocator.h structure
> opaque, I'd say we have a bit of worthwhi
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
> IMHO, the implementation is what people have tested, not the documented
> behavior. Use the source, luke :-)
But what I'm saying is that I don't think anybody *has* tested it. I
couldn't find a single use case in Apache where the called functio
201 - 300 of 729 matches
Mail list logo
