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, 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 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 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 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 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 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 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
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 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 (/
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 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 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 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 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 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 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
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:
> > 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
>
). 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
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
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
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
7;s not.
void apr_thread_yield()
{
}
Oh joy.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
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 -
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?
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 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.
Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
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
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
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
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
----
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
-----
On 11 May 2002 [EMAIL PROTECTED] wrote:
> +f->can_mmap = 1;
Great, thanks!
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
nitialize can_mmap in apr_bucket_file_make(), preferably to
true.
--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
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
perf.org
does
--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
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
1.0 release.
--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
---------
nge committed. Thanks!
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
able-atomic.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
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
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
--------
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
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
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,
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 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
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
--
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
ed access to the cleanup function itself, but it's static
to apr/mmap/*/mmap.c.
--Cliff
------
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
+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
. 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
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
--------
chunks, and then it
worked. Ridiculous.
--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
the same configuration as a
baseline?
Thanks!
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
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]
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
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
------
r can move on ;)
>
> +1. -- justin
+1
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
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
til APR 1.0 is finalized.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ing on it and get back to you asap.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ms) 8KB boundary. Either way's fine with me.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ist of Perl modules (wow), then
something more centralized perhaps. :)
--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
because I tried it once).
--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
his
pointer... did I miss one?
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
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
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
en. :)
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
padded out because they
can interfere with one another when you place the structs back-to-back in
memory.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
passes requests from one
thread to another mid-flight will *have to* have a group of bucket
allocators that it keeps around, assigning an available one to each
*connection* as it comes in -- ie, this one cannot be thread-private
like some of the others might be able to.
--Cliff
--
ould be much appreciated.
Thanks,
Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Thu, 28 Feb 2002, Cliff Woolley wrote:
> On Thu, 28 Feb 2002, Greg Stein wrote:
>
> > > /* prepend ctx->ssi_tag_brigade onto bb */
> > > APR_BRIGADE_CONCAT(ctx->ssi_tag_brigade, bb);
> > > APR_BRIGADE_CONCAT(bb, ctx->ssi_tag_brigade);
> >
&g
iom means
> "prepend". Yes, please add an appropriate macro.
Okay, will add.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
s equivalent to the above (except it runs in constant
time):
/* prepend ctx->ssi_tag_brigade onto bb */
APR_BRIGADE_CONCAT(ctx->ssi_tag_brigade, bb);
APR_BRIGADE_CONCAT(bb, ctx->ssi_tag_brigade);
But I'd be fine with adding a prepend macro in the API if others agree
it's useful.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
a workaround so
> I'd like to hear what others think first.
How about compiling and executing a test program and seeing what the
retcode is? Otherwise, +1 to the workaround.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
; > +#endif
>
> Shouldn't this be
> #if APR_HAS_THREADS
>
> i.e. isn't it always defined to either 0 or 1.
Yes, it should be.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Hello... we do it all the time. You read a *portion* and convert
> the bucket to something else. You then insert a new bucket after 'self' for
> the unread portion.
I'm sold. ++1
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
a large file down the filter stack, you make
multiple calls down the filter stack, one apr_size_t's worth at a time.
Thoughts?
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
akes sense... actually, is there ever a
reason for CHILD_DELONCLOSE? Or can I just register a child cleanup to
remove the DELONCLOSE flag from the child unconditionally?
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
lar bucket got
stuck in the brigade it's currently in is also valuable information...
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
anges, apr_bucket_read() would have to change, too. Is that
what we want? I'm not sure. Maybe it is...
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
apr_os_proc_t;
apr_portable.h:typedef pid_t apr_os_proc_t;
Just checking.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
happy to be told I'm imagining things and this just isn't a
problem... if that's the case, great!]
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
den requests are jumping from one thread to
another? Sounds like a big problem if thread-specific pools are in
place... is there an easy answer?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
I've recently started getting tons of these warnings:
libtool: link: warning: library `/usr/lib/libgdbm.la' was moved.
I talked to Ian about it, and we're sure it's related to the commit from
earlier today that enables multiple dbm types (I don't think my system
used gdbm previously, but I'm
s,
we abort and fall back on the read-8KB method. If the file is less than
APR_MMAP_LIMIT in size, we do the same thing we did before, ie, MMAP the
whole file. When all references to a given mmap go away, we delete the
mmap. If we're the owners of the MMAP (which we will be in this case),
that means we munmap the region.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
mail? :-) One at a time is
typically what you get with the code I posted anyhow since most filters
limit how much they'll buffer, but the one-at-a-time rule is just not
enforced. If it were enforced, then oh yeah, that would be bad. :)
--Cliff
---------
he stack, but I don't see that
as a problem.
What am I missing?
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Tue, 27 Nov 2001, Cliff Woolley wrote:
> APR_MMAP_LIMIT is exceeded. That's because we give up on mmap entirely
> and read 8kb at a time frome the whole bigass file, even if all we wanted
> in the first place was the first 32 bytes or so (say for something like
> mod_mime
301 - 400 of 729 matches
Mail list logo
