; +PROGRAMS = testdbm testdate testmd4 testxml
Did I miss something? Where is this testxml file?
Thanks,
Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ime I get an update from CVS.
Okay, no problem. Just checking. =-)
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
(sec * 1000) + (usec * 10) +
> +0x01B21DD213814000LL;
> +EnterDebugger(); /* Check to make sure that we are actually getting what
> we expect. */
> +#else
EnterDebugger()? Was that line supposed to get committed?
--Cliff
------
a that I can think of I hate, which is to
put the ->free pointer in the apr_bucket rather than in the
apr_bucket_type_t. That sucks. If you've got a better idea, I'm all
ears.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
same SMS).
THAT's the sms to use when freeing that apr_bucket, and it won't change
if/when we morph that bucket to a new type.
Unless you can think of a clean way around this problem, I think we need
to back out this patch.
--Cliff
--------
thing.
However: once we switch buckets to use SMS, none of this will really be
necessary... s/free/apr_sms_free/ in the apr_bucket_destroy() macro, and
then SMS handles the polymorphism for you. Just a thought.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
We've typically kept the history when we did this in the past,
but I don't much care.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Don't get me
wrong... ++1 for changing it in apr-util itself. =-)
BTW - The spiffy cool way to do file renames and get history preserved is
as follows:
(1) copy the ,v file to its new name
(2) move the old ,v file to the Attic
(3) remove all tags from the new ,v file
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Mon, 30 Jul 2001, David Reid wrote:
> OK, so how about we remove it during the buildconf stage - which is what I
> mean to say and for some reason didn't...
+1
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
had
buildconf run on it.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
/**
> * Setup the process for a single thread to be used for all signal
> handling.
>
Crap, I totally forgot you said that needed to be done. Thanks.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
her
> platforms shouldn't be affected, but please test.
>
> Brian, does this work for OS/2?
>
> Revision ChangesPath
> 1.347 +1 -0 apr/configure.in
Tested on FreeBSD, and it still builds. +1 to bump the tag.
--Cliff
-
r
than a full-blown function call...
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
o the buckets SMS thing, because I still want to
try it... after Apache 2 beta 2. =-)
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Win32, but there's got to be some way or another to do it...
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
boritory :)
heheh Yeah, that must be it. =-)
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
utting it in
but fat-fingered it.
The log message should read:
"Fix accept filters by making all the various macro names agree with each
other."
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Wed, 25 Jul 2001, Ryan Bloom wrote:
> This is most likely just a thinko on my part. Easy to fix, just use
> APR_HAS_SO_ACCEPTFILTER everywhere. :-)
Okay. Will patch this afternoon.
--Cliff
--
Cliff Woolley
lled
SO_ACCEPTFILTER. Is there any platform that defines SO_ACCEPT_FILTER,
which is what configure is currently checking for? If so, which one? If
not, I'll change configure.in and apr.h.in appropriately and go from
there.
Thanks,
Cliff
-------
were
just transposed. =-)
Committed.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
rwise, the struct passwd
> and the data pointed to by it (e.g., pw_name) are no longer valid
> storage when getpwnam_safe() returns
Oops! Good catch. Thanks. =-)
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
"
instead.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
7;s to enable the
> authorization and password creation.
Licensing issues? If it came out of glibc, surely it's GPL or LGPL... no?
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
er with an apr_sms_std as the parent sms for all sms's in the
child thread?
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ront if somebody needs a patch committed for them.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
s to be made (think mod_autoindex on a big
directory). If you don't clean up each subrequest after it happens, you
get a big ole' resource leak for the duration of the main request.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Therefore it's a problem with the people
and not the system, but either way it's just a pain.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
s out. It might just have to be an ugly hack.
:-/
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
it takes longer than the timeout
+1
(apr_wait_for_io_or_timeout() might want a better name if it's going
public, but that's just a nit)
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Patches for those would be fine by me, as well.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
API, looking for leads :(
Same here. :-/ Why does MS insist on reinventing the wheel?
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
n
apparently call RevertToSelf() which does what it sounds like. That's
generally undesirable in the contexts we're talking about...
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ht. Sorry, wasn't thinking. I guess we should
add that as a new function...
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
27;) [yes, yuck].
Take a look at apr_get_userid(), which among other things is in the "user"
subdirectory of APR.
> i love code that makes life easy.
=-)
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
7;m +1 on concept (haven't looked at the details of the patch yet,
but I will).
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
rec for each request.
Use that instead of the global apr_sms_std when creating
all buckets and get rid of the global apr_sms_std.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Sat, 7 Jul 2001 [EMAIL PROTECTED] wrote:
> I think you misunderstand my meaning.
Would you expect anything else? That's my specialty. ;-)
> We should do both.
Cool. +1.
--Cliff
------
Cliff Woolley
[EMAI
t, but it will take a lot of work and some pretty widespread changes to
put it to use, so an apr_pstrlencat() seems like a reasonable quick
fix/stopgap measure to me.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ughts?
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
functions in the list and many fewer calls to
apr_file_read().
I'm really interested in taking a look at the full data. Can you just
post it somewhere on the web and list the URL here?
Thanks,
Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Sat, 7 Jul 2001, Joe Orton wrote:
> The header doesn't mention what the function should return.
Committed. Thanks. =-)
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
rtunity to cut the httpd's CPU utilization nearly in half by
> tuning just the user-space code.
The flip side of that, of course, is that we could probably also get rid
of some useless/redundant system calls, thereby also reducing the time
spent in sys CPU.
--Cliff
-
uch cleaner and more reliable file buckets.
I'm dislike the idea of duplicating the file buckets in this way. But I'm
willing to change my mind if you can show me a way to do it that doesn't
duplicate much code and that works in all cases.
--Cliff
want to force my
> opinions on everybody.
Fair enough. =-)
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
rformance. However,
> the need to be performance aware can NEVER interfere with making the code
> work correctly.
Exactly.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Thu, 5 Jul 2001, Cliff Woolley wrote:
> The chunk filter.
s/chunk/byterange/
Duh.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
er. But
lseek() is probably doing the same thing anyhow...
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
split(c, 100);
APR_BUCKET_INSERT_AFTER(a, c);
apr_bucket_destroy(b);
apr_bucket_destroy(d);
You can't guarantee that consecutive reads from file buckets read from the
"next" spot in the file. In fact, they very frequently jump around.
--Cliff
--------
an's patch is a correct fix either way, not just a hack.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
this section for the common case. Only the
case where offset == 0 might be negatively impacted.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
part of the file BEFORE reading from the beginning of the file, which
isn't common in current Apache modules. Maybe we should come up with a
mod_scramble/mod_unscramble to test for weird stuff like this. =-)
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
so we're in the
"worst case" performance scenario anyway.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ition to lib/apr_pools.c which is wrong.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
s
implicit from the pcalloc). Right?
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
IZE ||
> APR_HAS_FLOCK_SERIALIZE
> new->interproc = -1;
> #endif
> #if APR_USE_PTHREAD_SERIALIZE
> new->intraproc = NULL;
> #endif
We didn't catch this part, though. The apr_lock_t is pcalloc'ed just
prior to calling create_lock(). Do we really need t
loop here... the recursion ought to take care of it
for you.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Sun, 1 Jul 2001 [EMAIL PROTECTED] wrote:
> Does this solve the warnings?
> If so, please apply.
Two problems:
(1) My system would never get into the elif because I have both SYSVSEM
and FCNTL serialize:
#define APR_USE_FLOCK_SERIALIZE 0
#define APR_USE_SYSVSEM_SERIALIZE 0
#define APR_USE_F
Just a heads up on some warnings I'm getting on Solaris 2.6 where
APR_USE_PROC_PTHREAD_SERIALIZE is selected:
locks.c: In function `apr_os_lock_get':
locks.c:344: warning: assignment makes pointer from integer without a cast
locks.c: In function `apr_os_lock_put':
locks.c:365: warning: assignment
t it'd be a useful option for testing things like this...
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
(). So then apr_sms_init() could set the type
pointer in the apr_sms_t and actually call apr_sms_malloc() if it needed,
calling back into the module via the type structure. That might be a
stretch, I don't know.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
oblems.
I know, I know... if I want it done, I should just patch the damn thing.
I'll try to get to it this weekend. =-)
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
d
> IDs registered with its children.
I guess a thread that registers its interest in a child SMS is by
definition 'interested' in all ancestors of that SMS...
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
27;t have to review that
> work?
+1. I'd been wondering about that myself as I've been tweaking various
API's.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ot
"own" the resource, then the caller is guaranteeing the buckets code that
no matter how long the buckets referring to that resource stay around, the
resource will not disappear out from under them. mod_file_cache could
make such a guarantee, for example.
Thoughts?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
;m guessing the
APR mmap code would have to get a similar flag. At that point, you only
have to lock accesses to the refcount if the apr_mmap_t was created in
APR_XTHREAD mode.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
t ourselves in
the foot in some other way. For example, will we then need a lock to
serialize access to the reference count?
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Tue, 26 Jun 2001, Cliff Woolley wrote:
> > Your right, this can do that. However, we really can't keep that from
> > happening. In reality, the mmap_setaside function should just map it back
> > to a file opened out of the new pool.
I see now that by "map it back
On Tue, 26 Jun 2001, Cliff Woolley wrote:
> > Your right, this can do that. However, we really can't keep that from
> > happening. In reality, the mmap_setaside function should just map it back
> > to a file opened out of the new pool.
>
> Hmmm... why's that?
nal descriptor has now been closed in kernel space?
> We'll have ourselves a nice invalid file descriptor. Or, am I
> wrong? -- justin
Oh crap, duh. You're 100% right. I now see the error of my ways. =-)
--------
e're done. What am I missing?
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ded. Make
sense?
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
> I'm with Ryan: dup the bugger.
It'd be nice if there was an apr_file_t_dup() [if you catch my drift...
I don't know what you'd really call it] that does everything
apr_file_dup() does *except* calling dup(). Then I'd have no problem at
all with this approach.
--C
drake's mistakes. If there was some way to put their names in
> the error, that would be even better.
> Unless groups hold RH and Mandrake accountable, they will continue to make
> irresponsible decisions.
Agreed.
--Cliff
------
ty as this then we should try
to inform the user somehow.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ttp://gcc.gnu.org/gcc-2.96.html
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
e
> of lines.
+1
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ss it while looking at the XTHREAD stuff.
And as it turns out, unfortunately, there was nothing quick about it...
that line's been broken for 11.5 months (since the pre-a5 era). :-/ Oh
well, it's fixed now.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ghts?
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Tue, 19 Jun 2001, Roy T. Fielding wrote:
> On Tue, Jun 19, 2001 at 08:30:13PM -0400, Cliff Woolley wrote:
> > In the following lines from readwrite.c line 90, should the if()
> > conditional clause really be an assignment, or is it a typo? It really
> > seems like it
))
return APR_SUCCESS;
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ithout passing it in as a parameter to
the buckets code, file_read() will have no idea which pool to use.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
nobody objects, I'll commit this tomorrow, followed closely by the
> > patch to mod_file_cache and the core_output_filter in Apache.
>
> Please give more time than one day when posting such large changes. This
> really deserves two or three days so that people who aren't reading e-mail
> everyday can try to keep up.
No problem. I'll wait until at least tomorrow, maybe Thursday.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
n mentions it... I guess a @see is appropriate at least). An
accessor function is not needed; all you have to do is just pretend that
it's a FILE bucket. It goes something like this:
if (APR_BUCKET_SUPPORTS_SENDFILE(e)) {
apr_bucket_file *f = e->data;
apr_sendfile(sock, f->fd, ...);
}
Easy, huh?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
asonably short, but if anybody has any better ideas, I'm all ears...
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Index: buckets/apr_buckets_eos.c
===
RCS file: /home/cvs/ap
t be available to us, and the
> original bug will be back.
Ahh, yes, I see the difference -- mod_file_cache knows a priori that the
pool the its cached file was opened into will live longer than the r->pool
it copies into, whereas this is just the opposite. Gotcha. dup() it is.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ype_t apr_bucket_type_immortal = {
+APU_DECLARE_DATA const apr_bucket_type_t apr_bucket_type_immortal = {
"IMMORTAL", 5,
apr_bucket_destroy_noop,
simple_read,
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
get() and
apr_os_file_put() to move the os file handle into it. mod_file_cache in
Apache does something like this. It should be cheaper to do this than to
do a full dup(), I think.
Thanks,
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
malloc_fn()) is to
check if the address is outside your single big block. If it is outside,
then you MUST have gotten that memory block from your parent. If it is
inside, then it MUST be one of your sub-blocks.
--Cliff
----------
Cliff Woo
the original block;
if so, add it back to the free_list, if not, call _free(parent,mem).
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Thu, 14 Jun 2001, David Reid wrote:
> The bucket structures are done from bms, allocations for data can come from
> either ams (some other type of sms yet to be added) or from the pms using
> plain old malloc. 8192 gives us space for 127 bucket structures per thread.
> If we need more we can a
and can just assume it exists. The buckets code
>
> Just to be safe...
Whatever. I guess it's there already, so no sense taking out a feature.
=-]
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
return APR_SUCCESS;
> }
I had been about to ask why you didn't just carve up the ->ptr into as
many blocks as possible in the create function and put them all onto the
free_list ahead of time so that you can use only the free_list in
_malloc()... but now I see why. =-) Clever.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
cally the textbook case for an immortal bucket, but I haven't
yet convinved myself that that will work in this case. I'll have to think
about this some more...
> and another for setaside using a pool. The problem with a single
> function is that buffering is very filter-specific.
Yep.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
file_t or an apr_mmap_t. It
would only work to just pass an arbitrary storage pointer if we actually
copied all of the data represented by the bucket into that buffer, and
that's not the idea at all.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
ms->parent" would be ideal, but then again "sms->ref" wouldn't
make much sense, so for consistency I could live with "sms->parent_sms".
=-)
PS: If this post makes no sense, please tell me.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
; consider my vote -0.9 (because I'm that close to vetoing it, but
> I'm not going to do that). Hopefully, my intention *not* to veto
> is and was clear.
It was.
> My apologies.
No sweat. =-)
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
or something. =-) Only
in non-consensus-requiring matters do -1's count as "negative votes", but
those matters seem to only exist in administrative matters, not code
matters.
--Cliff
----------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
rking a
new memory allocator (whichever allocator that ends up being). Initially
I'll just use the sms_std malloc() style allocator, of course. Hopefully
the initial migration will happen sometime this week. Hopefully.
--Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Is
that right?
Thanks,
Cliff
------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
y and prove our case. If we don't prove anything issue
> a -1 later and we'll cut the code out [does this sound fair David?]
Okay by me.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
501 - 600 of 729 matches
Mail list logo
