--- Greg Stein [EMAIL PROTECTED] wrote:
Well, it has been suggested that we create a new APR utility library. The
discussion on that *just* opened today. It looks like we have several +1 on
the concept, and I posted an outline of my thoughts on it.
It's cool with me. That thread started
Okay, I realize that apr-util was just born :), and what's in there right now is
basically just a first pass to facilitate the move to the httpd-2.0 repository
for
Apache. So thiss is as much to make sure that I understand the intentions as
anything else.
1) I assume that the ap_* prefix on
--- Greg Stein [EMAIL PROTECTED] wrote:
I've applied the patch because it is a good start.
However, ap_bucket_split_any() is not yet right. If a caller says split at
1, then it will probably fail because the read() won't read in that
much. You need to read enough buckets, until you read
--- [EMAIL PROTECTED] wrote:
wrowe 00/12/08 08:10:33
Modified:.aprutil.dsp
include ap_buckets.h
src/buckets ap_buckets_refcount.c
Log:
Buckets build again on Win32
Thanks. I'm still not 100% clear on when to use *_DECLARE_NONSTD
The recent change to use APR_HAVE_*_H macros in the Apache support files forgot
one
little bit, which broke the build.
--Cliff
Index: configure.in
===
RCS file: /home/cvspublic/apr/configure.in,v
retrieving revision 1.193
diff -u
--- Greg Stein [EMAIL PROTECTED] wrote:
Now that we're actually using this function, I figured it was time to dig in
and spend the time with this patch. :-)
Cool. Just so you know, I've been kind of out-of-touch with the list for a
while, since
the 1000+ messages that accumulated while I was
--- Greg Stein [EMAIL PROTECTED] wrote:
Now that we're actually using this function, I figured it was time to dig in
and spend the time with this patch. :-)
*) what happens when you find a bucket with e-length == -1 ? AFAICT, the
function doesn't handle it. I'm thinking a check at the top
--- [EMAIL PROTECTED] wrote:
+/* Leap year is any year divisible by four, but not by 100 unless also
+ * divisible by 400
+ */
+#define IsLeapYear(y) ((!(y % 4)) ? (((!(y % 400)) (y % 100)) ? 1 : 0) :
0)
+
If y is divisible evenly by 400, it's automatically divisible by 100... you
don't
--- Cliff Woolley [EMAIL PROTECTED] wrote:
If y is divisible evenly by 400, it's automatically divisible by 100... you
don't need
to check both. =-)
That's what I get for talking before I think... I guess you actually DO have to
check,
since you have to be sure that if it's not divisible
--- [EMAIL PROTECTED] wrote:
+APR_DECLARE(void *) apr_memdup(apr_pool_t *a, const void *m, apr_size_t n)
+{
+void *res;
+
+if(m == NULL)
+ return NULL;
+res = apr_palloc(a, n);
+memcpy(res, m, n);
+return res;
+}
+
Nice. Minor question,
-Original Message-
Or do you mean a
full patch to mass-cleanup all callers of the macros throughout Apache?
I meant the latter. I can apply what you already sent in about an hour, I
need to get to the office soon. All that's left is the rest of the
cleanup. :-)
Ahh. =-) Well
Doug MacEachern [mailto:[EMAIL PROTECTED] wrote:
i can take care of these no problemo.
Cool, thanks.
--Cliff
didn't think so. ;-] It's on my short list.
--Cliff
---
Cliff Woolley
[EMAIL PROTECTED]
804-244-8615
Charlottesville, VA
-Original Message-
Cliff, you just hit on two things that I have spent a lot of time thinking
about, so I'll give my opinions to add to your own.
Glad it's not just me. =-)
I realized that combining them wasn't as easy as you would
think. The first option is to always destroy
--- Jeff Trawick said:
(by the way, we don't build with the HP compiler on HP 10.20; need to
look lots further into which compiler I have access to and why it
doesn't like some seemingly benign declarations in APR)
That doesn't surprise me... HP-UX's native compiler has been known to do
some
a
configuration script generated by Autoconf, you may include it under
the same distribution terms that you use for the rest of that program.
Looks okay to me...
--Cliff
---
Cliff Woolley
[EMAIL PROTECTED]
804-244-8615
reason that there are
no Netware files at all in APR. Hmph.
--Cliff
---
Cliff Woolley
[EMAIL PROTECTED]
804-244-8615
Charlottesville, VA
On Tue, 20 Feb 2001, Greg Stein wrote:
Okay, people. Here is your chance to vote.
add 2.0 symbol renames to ap*_compat.h:
-0: Greg, Doug
I don't know if I get to vote or not, but I'm -0 anyway. :-]
--Cliff
-Original Message-
There is a bug report about this too. Please fix it. :-)
There's a patch in the PR (actually very similar to what Manoj originally
committed with the function and later removed). But it's not threadsafe (which
seems to be why Manoj removed it in the first place).
Just a heads up on something I ran across a day or so ago in case you all
get a chance to look at it before you roll again (I probably won't have a
chance to look at it before then).
I'm still having problems with an incorrectly detected number of arguments
to sigwait on SunOS as of Friday, I
On 26 Feb 2001, Ben Collins-Sussman wrote:
#if APR_HAVE_SYS_SENDFILE_H
#include sys/sendfile.h
#endif
And, of course, my system has no sys/sendfile.h. :)
I know that there's been a recent thread on this list about
sendfile.h, but I have to admit that I didn't read it. (*blush*) Can
On Mon, 26 Feb 2001, Jim Jagielski wrote:
Use APR_CHECK_HEADERS instead
Before I go any further, I want to rethink the name. Maybe APR_FLAG_HEADERS
(want to avoid confusion here) or APR_HEADERS_SET. Suggestions
welcome.
APR_CHECK_HEADERS doesn't bother me... it makes it clear that
On Mon, 26 Feb 2001 [EMAIL PROTECTED] wrote:
3) pool_bucket_cleanup() is completely bogus AFAICT. I've added this
comment to the code, which describes the problems pretty well:
4) The same problem applies to file buckets that have been split/copied
when APR_HAS_MMAP: when one of them
On Tue, 27 Feb 2001, Greg Stein wrote:
Euh... I don't think we want another ring.
A simpler idea is to have the apr_bucket_pool structure contain a pointer to
an apr_bucket_heap structure. At cleanup time, you do the following:
Ahh, (he says as the little light over his head comes on). This
On 28 Feb 2001 [EMAIL PROTECTED] wrote:
Fix some warnings related to the fact that you can't do arithmetic
with a void *.
Oops, sorry about that. Didn't get the warning on my Linux box. Thanks
for the fix.
--Cliff
Why do we need an array of all the bucket types, and therefore
apr_bucket_init_types() and apr_bucket_insert_type()? I seem to recall
that this was necessary in the very early days of the bucket API. But I
can't see any reason to keep them anymore. (The error bucket gets by
without registering
On Tue, 27 Feb 2001, Cliff Woolley wrote:
Nothing uses the array that gets built. Can anyone think of a reason
I shouldn't delete the array and these two functions?
Alright, they're going away. apr_bucket_insert_type() doesn't even work
right. (The second assignment should be to *newone
On 28 Feb 2001 [EMAIL PROTECTED] wrote:
buf = malloc(APR_BUCKET_BUFF_SIZE);
b = apr_bucket_heap_create(buf, APR_BUCKET_BUFF_SIZE, 0, NULL);
APR_BRIGADE_INSERT_TAIL(bb, b);
+b-length = 0; /* We are writing into the brigade, and
+
On 28 Feb 2001 [EMAIL PROTECTED] wrote:
buf = malloc(APR_BUCKET_BUFF_SIZE);
b = apr_bucket_heap_create(buf, APR_BUCKET_BUFF_SIZE, 0, NULL);
On a side note, we currently have two macros that do almost the same
thing: APR_BUCKET_BUFF_SIZE (=9000) which determines
On Wed, 28 Feb 2001 [EMAIL PROTECTED] wrote:
I like making APR_BUCKET_BUFF_SIZE == 8192 [and using it]
Okay, I'll do that.
and removing the other.
HUGE_STRING_LEN comes from apr_lib.h, not from within aprutil, and other
parts of APR (and maybe Apache, too) are using it. It ought to be
On Tue, 27 Feb 2001, Greg Stein wrote:
Euh... I don't think we want another ring.
A simpler idea is to have the apr_bucket_pool structure contain a pointer to
an apr_bucket_heap structure. At cleanup time, you do the following:
...
So what you get here is a single allocation of a heap
On 28 Feb 2001 [EMAIL PROTECTED] wrote:
pass the right value to free() to prevent segfaults and corrupted
heaps and other nasties
Ugghghhh... damn me. I'm just causing all sorts of problems, aren't I?
sigh
--Cliff
On Wed, 28 Feb 2001, Greg Stein wrote:
1) it is hard to tell that p and h refer to the same bucket.
p-heap.foo is more obvious than h-foo.
Fine by me.
2) Nit: I'm getting tired of these single letters for the bucket stuff. a
as a variable for a bucket? e? Blarg. Using h and p fall
a
* filter wants to pass only the initial part of a brigade to the next
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
to do
multiline macros (to allow the macro user to place a semicolon after the
macro invocation without causing a syntax error), so I'll agree with
Ryan: it's a bug in your compiler.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
);\
} while(0)
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
() and
apr_bucket_foo_make, but it shouldn't matter since the two never touch
each other's data (and if they did, it would be better for the init to
happen first anyway).
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville
compilers (notably MSVC). What
used to be done by this macro is now done inline in the various
apr_bucket_foo_create() functions. [Cliff Woolley]
I presume that your warnings are now gone, right?
--Cliff
--
Cliff Woolley
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
break the module
that caches FD's. I've got a proposed fix for that as well.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
object in our sideband discussion). I'll do that ASAP.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Sat, 28 Apr 2001 [EMAIL PROTECTED] wrote:
Yes, which is exactly the bug that Dean pointed out over three months,
ago, and which I posted a potential fix for. Cliff Woolley is actually
implementing it AFAIK.
I didn't know I was, but I am now. =-)
--Cliff
it earlier today.
No problem. I think Justin might beat me to it (not trying to volunteer
HIM, mind you grin). It'll get done one way or the other. =-)
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
to be the
symbol of which you speak.)
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Mon, 30 Apr 2001, Cliff Woolley wrote:
This is definitely better than the leak. =-) And nothing says that the
cache can't apr_mmap_delete() the MMAP associated with the master file
bucket as long as refcount==1 (ie, there are no requests using that
file/mmap currently in progress
to use this feature directly.
Sounds like the SMS (stackable memory system) stuff that the Samba-TNG
guys have proposed for APR might be worth some investigation...
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
at this section of the code itself yet),
assignment IS what's intended here, right? If so, a ((foo = bar) != NULL)
might make that more clear.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
general cases? (I can't
think of a good example at the moment, but I hope you see what I'm getting
at anyway.)
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
code, then yes, it would go in apr-util. But that's
not the goal, so it goes in APR.
My $0.02.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
, so providing the functionality wouldn't be that
strange I think.
Legal issues aside, my only worry is that we seem to be duplicating more
and more of the effort of the OpenSSL team...
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
. If it came off as a personal thing, I
apologize... that wasn't the intent.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On 5 Jun 2001 [EMAIL PROTECTED] wrote:
--- apr.h.in2001/05/10 18:09:26 1.80
+++ apr.h.in2001/06/05 08:15:05 1.81
@@ -174,6 +174,8 @@
typedef @off_t_value@ apr_off_t;
typedef @socklen_t_value@ apr_socklen_t;
+typedef struct apr_lock_t
the way you've done it. Thanks.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
;
return mem_sys-lock_fn(mem_sys);
Ahh, that makes sense. My bad. Thanks, David.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
matters do -1's count as negative votes, but
those matters seem to only exist in administrative matters, not code
matters.
shrug
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
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
, 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
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
. The problem with a single
function is that buffering is very filter-specific.
Yep.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
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
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
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 Woolley
[EMAIL PROTECTED
be cheaper to do this than to
do a full dup(), I think.
Thanks,
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
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
...
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Index: buckets/apr_buckets_eos.c
===
RCS file: /home/cvs/apr-util/buckets/apr_buckets_eos.c,v
retrieving revision 1.25
diff -u -d -r1.25
)) {
apr_bucket_file *f = e-data;
apr_sendfile(sock, f-fd, ...);
}
Easy, huh?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
. 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
, 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
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
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.
--Cliff
--
Cliff Woolley
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 to a file you meant reopen
wondering about that myself as I've been tweaking various
API's.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
, I should just patch the damn thing.
I'll try to get to it this weekend. =-)
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
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
like this...
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
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:
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
of it
for you.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
, though. The apr_lock_t is pcalloc'ed just
prior to calling create_lock(). Do we really need to do this? If so,
feel free to add it in...
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
is wrong.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
. Only the
case where offset == 0 might be negatively impacted.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
(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
--
Cliff Woolley
--
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
1 - 100 of 538 matches
Mail list logo
