oy(m)) {
-/* no need to apr_mmap_delete(m->mmap) here... it will
- * get done automatically when the pool gets cleaned up. */
+apr_mmap_delete(m->mmap);
free(m);
}
}
[Tested to compile but not to work ;]
Thoughts?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
x27;ll do this in APR_MMAP_LIMIT chunks (which I think is
> 4MB). So, it might balance out. -- justin
Hopefully.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
me before that what happens with the code
now on a file bigger than APR_MMAP_LIMIT is that we get a bunch of 8KB
heap buckets until there is <= APR_MMAP_LIMIT _left_ in the file, and that
last bit of the file is mmaped. So we have a bunch of 8KB heap buckets
followed by a 4MB-ish mmap. Man, that's weird. :)
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
hould be pushed down into
APR from APR-util in some way. It definitely shouldn't go UP into Apache,
though.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
it wishes to
share across threads. It's up to APR/APR-Util to deal with that reality
from then on.
> just doesn't seem like bucket_read() is the right place for this
> logic.
It is. I promise. :)
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Tue, 27 Nov 2001, Cliff Woolley wrote:
> It's theoretically possible for it to happen if you've split or copied
> your file bucket _before reading from it_ the first time.
Nope, scratch that, it won't even happen in that case. Duh. The
split/copied file bucket
not a really easy way to keep track of when you need to
seek and when you don't, so we just do it all the time. You could come
up with some kind of logic to set a variable that says whether it's been
split/copied or not, and if not, then you can skip the seek, but I think I
came up with a case once where even that would break.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Tue, 27 Nov 2001, Doug MacEachern wrote:
> On Tue, 27 Nov 2001, Cliff Woolley wrote:
>
> > +1 on concept, but if you're going to do this, the things need APR_
> > namespace protection.
>
> ok, wasn't sure if those values might already be defined in a syste
u're going to do this, the things need APR_
namespace protection.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
otherbill's note about using a clean checkout once a week or
something... that sounds like a good idea to me.]
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
636)
prefix decoded = DCBA
Mine:
key = abcDEFghiJKLmnoPQRstuVWXyz
key prefix = 0x44434241 (1145258561)
prefix decoded = ABCD
Got a good way for me to benchmark these? Just run them a million times
and see how long it takes?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
here might be some pools between a and b for the diagram
to be exactly right, but the hierarchy is essentially correct I believe.)
Granted, in that particular example, c lives much, much longer than b, but
in general that's not at all guaranteed to be the case.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
rameter and make it very fast,
whereas the generalized memcpy() routine is a big ol' bugger.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
t-uncle or
something ;). FEH. Is there some clean way we can allocate the mmap out
of a better pool than the cmd->pool [like pchild or something]? The less
work we do at request time, the better. I guess this wouldn't be the end
of the world, though.
--Cliff
to remove the sub-pool from the
> core_output_filter. I need to understand why we have it first though.
I'll have to look more at that, too... it does seem like a possible
alternative.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
like bad mojo to me...
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
n mmap_setaside was
making me queasy. :-)
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ancestor pool and tweak the cleanups.
In the case of disjoint pools, it could do something else (what I haven't
decided yet). Then mmap_setaside() becomes as easy as file_setaside() is.
Thoughts?
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
;re done with
it rather than growing the pools to be really huge forever...
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
e opinion that this was the way to go...
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
arguably be easier to read... so +1 to either variant
from the Win32 peanut gallery (I'm taking your word for it that this is
the right fix since I know next to nothing about the Win32 API... I'm just
saying +1 because I now believe the logic is correct).
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
CRYPT_NEWKEYSET))) {
6 return apr_get_os_error();
7}
8}
Note in particular line 3. We want to call apr_get_os_error() if _either_
the last error was not NTE_BAD_KEYSET _or_ the CRYPT_NEWKEYSET thingy
failed.
Is that right?
--Cliff
move is doable, at least.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On 19 Oct 2001 [EMAIL PROTECTED] wrote:
> bnicholes01/10/19 12:28:55
>
> Removed: misc/netware aprlib.imp
> Log:
> No longer needed. This file is generated by make_nw_export.awk.
VERY glad to hear it. :)
----
apr_bucket_heap_make(b, addr, b->length, 1, NULL);
}
mmap_destroy(m);
}
}
return rv;
}
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
if you
want to sleep just long enough to ensure that the mtime will be different,
what do you do? I guess you have to assume worst case... (is that 1s or
is it more than that?)
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ckets code
can use internally but that it should hide from the caller.
I thought we had already documented that EAGAIN or SUCCESS could be
returned for nonblocking reads, but if we haven't, then yes, it definitely
needs to be done.
Thanks for the patches to revert this and fix the core, btw.
--
On 10 Oct 2001 [EMAIL PROTECTED] wrote:
> -#ifdef APR_HAVE_STDINT_H
> +#if APR_HAVE_STDINT_H
Crap, I meant to fix that. Thanks, Brian.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
#x27;t move on to the next bucket prematurely, we're fine.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
p filename that has been
> created that way is unsafe.
Oops, left one off the list:
- removed unused domkdir functionality from gettemp
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
s that don't have mkstemp. I'll fix that and
clean up some other cruft while I'm at it. Thanks for the patch!
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ool_cleanup_kill(file->cntxt, file, apr_unix_file_cleanup);
return apr_unix_file_cleanup(file);
}
Which is exactly equivalent to what apr_dir_close() does now that it's
been fixed. Thoughts?
--Cliff
----------
Cliff Woo
X, because I
> really don't like the name mkstemp. :-) We are making a temp file.
> I think the name expresses that well.
Works for me. I don't much like "mkstemp" either. Just thought I'd
double-check.
--Cliff
--------
. mkstemp() is what does that.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
tore, I guess
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
nted in the above message? That'd be great.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
checking for os2.h... no
decision on shared memory allocation method... SysV IPC shmget()
$ make >/dev/null
sockets.c: In function `apr_connect':
sockets.c:269: warning: passing arg 2 of `connect' discards qualifiers
from pointer target type
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
tried compiling on Solaris at all in the last few weeks...
I've mainly been working on Linux 2.4 lately. I'll give it a try on Sol
2.6 and see what happens.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
s was the best option we could come up with...
I'm still convinced it's the best way to go.)
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
e Ryan just beat me to
it. Thanks!
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
aved_lengths[nargs++];
> +}
> +else {
> +len = strlen(argp);
> +}
> +
>memcpy(cp, argp, len);
>cp += len;
>}
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Wed, 26 Sep 2001, Cliff Woolley wrote:
> str = apr_psprintf(p, "\n\n\n\n%s\n\n\n\n",
>ap_psignature("", r));
> e = apr_bucket_pool_create(str, strlen(str), p);
> APR_BRIGADE_INSERT_TAIL(out, e);
Or, alternately (meant to ment
mod_proxy... I just made up the second version as food for thought.]
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
(If you pass in more than
> 6 strings to concatenate, this optimization just gets applied to the
> first 6.)
Ahh, how I wish we had those nifty counted strings. But anyway, since
that's not gonna happen anytime soon, +1.
--Cliff
-------
actly_ the same.
[I'll reiterate my agreement that it should be a pointer to the allocation
object and not some arbitrary index int.]
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
nk "the APR group should handle this". Whatever... I don't really care
where it goes. I just think it's a really good idea in general.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
from me as well.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
r methods, it doesn't have
to know, because all of the freelist instances are independent.
Looking up the freelist for a single-threaded app would be the
essentially the same as it looking up for an app with dynamic numbers
of threads.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
s long as they
get stored somewhere in Apache and not in apr-util I'm happy.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
or whatever I called it... the caller really
doesn't much care what it receives and passes back. The only difference
is that with a generic "unique ID", the caller can make up their own.
That just means more work for us though. Whatever.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
therwise
totally internal to me."
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
request_rec*, without
> having to look up and hash the current thread ID for every bucket
> alloc/split/free.
Precisely!
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
themselves call
apr_os_thread_current() or something every time you create a bucket...
wow, that would get really expensive really fast. Or have I missed your
point?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
erent ways, but I'm now convinced that this is the right way to go, so
I guess I just have to go and do it if I'm going to convince you all as
well. =-)
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ve gotten rid of that registration stuff the first time
around. If anybody has other suggestions, I'm all ears...
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
tr) {
apr_bucket *b = ptr;
free_the_damned_thing(b, b->list);
}
Because b->list will point to the wrong spot in the thing pointed to by
ptr.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
a
parameter for those bucket types that might still want to use malloc/free
directly... ugh.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
th one free list, all blocks allocated would be the same size.
That's clearly the absolute fastest way to allocate these things. Is it
safe?
Thoughts?
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Mon, 24 Sep 2001, Joshua Slive wrote:
> Could someone with the correct access point the image on the
> apr webpage at http://www.apache.org/images/asf-logo.gif
> rather than its current location.
I'm on it.
--Cliff
-
o that
thread. They don't have to worry about shoehorning the value into the
range 0..num_threads. I fear that if we use a static array we're tying
this too closely to httpd, and more than that to current MPM's for httpd.
Thoughts?
--Cliff
PS: Why is conn_rec->id a long and not an APR type?
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
d be set to 1
regardless of the INT64_C thing if it's present. 2) APR_HAVE_STDINT_H is
missing from apr.hw.
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Mon, 3 Sep 2001, Ryan Bloom wrote:
> On Monday 03 September 2001 18:49, Cliff Woolley wrote:
> > On Mon, 3 Sep 2001, Ryan Bloom wrote:
> > > I seriously dislike adding an SMS to every bucket. I believe we are
> > > much better off just creating a per-thread free buc
Thanks! That's very helpful.
> Unix hacks, where is yours :-?
Ours isn't that hard. ;-) Seriously, though, what would go in it? If
anyone can think of some FAQ's for building on Unix, I'd be happy to
compile them...
--Cliff
---------
p now.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
hanks.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
t tmpnam()...
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Wed, 19 Sep 2001, Cliff Woolley wrote:
> Don't remove them it I've un-depended buckets on it!! :)
s/them it/it until/
7;ve un-depended buckets on it!! :)
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
week.
(I assume by "uses the pools" you mean the free-list stuff, which is what
I'm working on, but which is not pools in the apr_pool_t sense. There are
no plans that I know of to make buckets use apr_pool_t's any more than
they already do.)
--Cliff
------
t need me to tell you that for you to
know it was done. ;) ]
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ttr->child_err)
> +if (attr->child_err && attr->child_err->filehand)
>si.hStdError = attr->child_err->filehand;
This shouldn't be required. The original version set all three
si.hStdfoo's unconditionally. Just checking attr->child_foo to avoid a
segfault is sufficient.
Thanks,
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
;child_out->filehand;
> +if (attr->child_err)
> +si.hStdError = attr->child_err->filehand;
>}
>
> rv = CreateProcessA(progname, cmdline, /* Command line */
So now si.dwFlags will be set to |= STARTF_USESTDHANDLES even if
all of the ->filehand's are zero. Is that right? Just checking.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
n on the same wavelength? Is this in fact what you had in mind?
If not, what?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Okay, so since some of you were displeased with the size of the phase 1
patch that I committed, here's your chance to review phase 2 beforehand.
Assuming you all approve of this, I'll patch httpd to match.
--Cliff
--
Cli
ly return APR_ENOTIMPL so that the caller
has some way to know that *dirname (in this example) was not set so it can
avoid a segfault if it wants...
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
s? It was always
such a PITA to maintain this stuff in version control. It was
_constantly_ out-of-date. Why won't an auto-generated version work here?
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
a
macro would have been a good idea. I'll keep that in mind if I ever have
a need for something like this again.
Thanks,
Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Sun, 26 Aug 2001, Greg Stein wrote:
> On Sat, Aug 25, 2001 at 05:09:14PM -0400, Cliff Woolley wrote:
> >...
> > APU_DECLARE_NONSTD(apr_status_t) apr_bucket_simple_split(apr_bucket *a,
> > -
r a buckets-specific-non-SMS free list, so you'd end up
doing the call to find out what your thread ID is and then do your hash
lookup because the caller can't help you anymore.
So that was the logic behind it.
Thoughts?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
that's the one I picked. =-)
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Should the new apr_sms_t* parameter to the foo_create() functions go at
the beginning of the argument list or at the end?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
inate length.)
Huh? I can't grok what you just said for some reason.
Anyhow, I don't think it matters... I think I've figured out the answer to
my original question. We should be able to just test point against
a->length and ignore the possibility of it being "negative"
What am I missing?
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
will help with buckets... I just haven't gotten around
to patching them yet to try it. I'll try to get back into that soon.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
probably more
easily extensible by an outside module that might know about some flavor
of dbm we don't know about. But that's just me.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
t's what we want. I'll have to think
about this some more.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ks for looking into this, but we need to keep looking for the source
of the NULL parameter rather than bandaiding it.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
u should move the while test up to the top of the loop, I
think.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
something other than char* or void*, they can just
deal. =-)
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
because that's the biggest the bucket can be anyway. Something within
ap_http_filter needs to handle the conversion, I'd expect.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Tue, 7 Aug 2001, Cliff Woolley wrote:
> > + if ((rc = getsockopt(sock->socketdes, SOL_SOCKET, SO_ERROR,
> &error, &len)) < 0) {
It seems that len really ought to be an int, not an apr_size_t... I'm
getting incompatible pointer type warnings on Solaris.
I checked
er.
+1.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
consistent. Put it in the pool.
Huh? What pool?
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
O_ERROR, &error, &len))
> < 0) {
> -return(rc);
> +if ((rc = getsockopt(sock->socketdes, SOL_SOCKET, SO_ERROR,
> &error, &len)) < 0) {
> +return errno;
>}
>if (error) {
>
On Tue, 7 Aug 2001, Cliff Woolley wrote:
> On FreeBSD (icarus) now:
>
> /bin/sh /x1/home/jwoolley/httpd-2.0/srclib/apr/libtool --silent
> --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes
> -Wmissing-declarations -DHAVE_CONFIG_H -D_REENTRANT
On Tue, 7 Aug 2001, Cliff Woolley wrote:
> On 7 Aug 2001 [EMAIL PROTECTED] wrote:
>
> > rbb 01/08/07 16:56:35
> >
> > Modified:network_io/unix sockets.c
> > Log:
> > Finish the fix for the non-blocking connect. Basically, we need to
>
> is done using getsockopt with the SO_ERROR option. If error == 0, then
> the connect succeeded, else error is the connect errno value.
> Submitted by: Jeff Trawick
This did make it in before the 2.0.23 tag, by the way...
--Cliff
----
; the variable is only set if there is a error.
>
> I don't know of any other way (except for passing a error-buffer into
> the call) of getting the XML specific messages out.
I'll let you guys figure out the best way to handle this, and it can be
patched later.
Thanks,
Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Tue, 7 Aug 2001, Cliff Woolley wrote:
> > and I've re-attached testxml.c (as well as in-lined it)
>
> Oh, my fault, I just didn't see the attachment hiding down there the first
> time. =-)
>
> Taking a look at this now...
Well, my only complaint so far is th
On 7 Aug 2001, Ian Holsman wrote:
> and I've re-attached testxml.c (as well as in-lined it)
Oh, my fault, I just didn't see the attachment hiding down there the first
time. =-)
Taking a look at this now...
--Cliff
--
401 - 500 of 729 matches
Mail list logo
