Where does it say that? httpd uses it extensively, so if it's not, I'd
tend to think we'd have noticed by now...
--Cliff
On Thu, 8 Jan 2004, Donald Doane wrote:
> Okay, will do that, but it's called in
> "flood_easy_reports::easy_process_stats()" and it seems APR
> documentation implies it is
On Thu, 8 Jan 2004, Sander Striker wrote:
> Doable. Should be a fairly tiny patch to make this possible. It would
> be a 'BEWARE! USE AT OWN RISK!' feature, since you are going to mess
Hah, like I said, Sander's the man. :-)
On Wed, 7 Jan 2004, Dipak Patel wrote:
> This is the third time I'm asking this question. Can anyone please tell me
> how to use some built in feature of the apr memory pool module to move a
> sub-pool to under another pool? Our software makes use this type of feature
> to pass messages from on la
On Fri, 2 Jan 2004, Stas Bekman wrote:
> Though I think it should be NUL-terminated, since NULL stands for a 0 pointer,
> not '\0'.
ya ya ya ;)
:)
--Cliff
On Wed, 31 Dec 2003, Stas Bekman wrote:
> > - * @remark The buffer will be '\0'-terminated if any characters are stored.
> > + * @remark The buffer will be '\\0'-terminated if any characters are
> > stored.
>
> Can't this be worked around in some other way? People reading raw .h files may
> get co
On Wed, 24 Dec 2003, Evan Easton wrote:
> > We NEED BADLY separate apr-0.9.5 release for FreeBSD ports (for
> > example, to allow build new subversion without apache).
> > Please, please, release it!
> >
> Ditto that!
I'll get on that ASAP... but Christmas Eve is not the day of the year I
have
On Thu, 18 Dec 2003, Bojan Smojver wrote:
> You can put on the list of projects using APR my own mod_spin
> (http://www.rexursive.com/software/modspin/). Not only does the module
> use APR, but also the applications written for it use APR. Also, the API
> that the module provides relies heavily on
On Wed, 17 Dec 2003, Brad Nicholes wrote:
> Thanks. After doing some more digging I also ran across this chunk
> of code myself. Casting the filesize to apr_size_t in the #else part of
> the code was a dead give-away. I guess NetWare hit the odd combination
> here in that we don't have send
On Wed, 17 Dec 2003, Brad Nicholes wrote:
> before setting the content-length header. The problem is that there
> appears to be only one bucket and the length of that bucket is
> (actual_filesize - 4gig) for any file greater than 4gig.
Weird, but I can believe it.
> Where should the dividing up
On Wed, 17 Dec 2003, Brad Nicholes wrote:
> incompatibilities in the bucket code. There are a number of places
> where file lengths are defined as apr_size_t rather than apr_off_t.
> What is the downside of redefining these variables as apr_off_t (ie.
> off64_t rather than off_t)?
We went back a
On Sun, 14 Dec 2003, [ISO-8859-15] André Malo wrote:
> > Acrobat Reader is just about the only client I know of that actually uses
> > byte range requests. So if PDF serving to acroread is broken, the
> > byterange filter is virtually always the culprit.
>
> Nah, every download manager (e.g. wget
On Sat, 13 Dec 2003 [EMAIL PROTECTED] wrote:
> bnicholes2003/12/13 12:32:49
>
> Modified:include apr.hnw
> Log:
> large file support is causing problems with acrobat reader and PDF
> files. Turning it off on NetWare until I can figure out why.
Acrobat Reader is just about the only
On Tue, 9 Dec 2003, Mladen Turk wrote:
> That was the bug.
>
> > if not returning whatever apr_thread_cond_timedwait()
> > returned, why not return APR_TIMEUP instead of APR_EAGAIN?
> > but like Cliff said I wonder why the retval of
> > apr_thread_cond_timewait() isn't appropriate?
>
> The fixed p
On Tue, 9 Dec 2003, Jeff Trawick wrote:
> > +if (reslist->timeout) {
> > +if (apr_thread_cond_timedwait(reslist->avail,
> > +reslist->listlock, reslist->timeout) != APR_SUCCESS)
> > +apr_thread_mutex_unlock(reslist->listlock);
> > +
On Mon, 8 Dec 2003, Mladen Turk wrote:
> Can someone review this patch and eventually respond if there are
> any chances to get this patch committed to apr-util.
> If not we'll make something different then.
I think it would have to be called apr_reslist_timeout_set() rather than
apr_reslist_set_
On Fri, 5 Dec 2003, Kevin Wang wrote:
> In the past a few days, I was trying to figure out a shared memory
> corruption problem in my module. Eventually I found this bug in
> apr_rmm.c's find_block_of_size() function. It is severe enough to mess
> up the whole rmm memory blocks and make apr_rmm_*
On Mon, 24 Nov 2003, Norman Tuttle wrote:
> Attached are the diffs to the three operating system files for
> apr_socket_connect() within sockets.c Good idea to make sure these work
> within Unix & OS2 environment; I compiled under Win32. The patch should
> address the issue below.
Seems reasona
On Thu, 30 Oct 2003, Norman Tuttle wrote:
> What is the latest stable build of the Apache APR, when was it produced,
I was supposed to tag and roll 0.9.5 and 1.0-test1 yesterday, but got
sidetracked and forgot about it. I'll try to do it today.
--Cliff
On Wed, 29 Oct 2003, Joe Orton wrote:
> I wrote this when tracking down that psprintf bug, I think it makes the
> code a little clearer than trying to follow the pointer juggling
> everywhere. Any objections to committing it? (object code is
> byte-for-byte identical before and after)
I like it.
I'm planning on rolling 0.9.5 and 1.0-pre1 tarballs tomorrow (Wednesday)
unless somebody has strenuous objections.
--Cliff
> Starting httpd: /usr/sbin/httpd: relocation error: /usr/lib/libapr-0.so.0:
> symbol sys_siglist, version GLIBC_2.3.3 not defined in the file libc.so.6
> with link time reference
> Is this a problem with glibc (I have 2.3.2) not being the correct version or
> is it an actual apr problem? If it is
On Tue, 7 Oct 2003, William A. Rowe, Jr. wrote:
> Perhaps apr_brigade_t says it all...
+1.
On Tue, 7 Oct 2003, William A. Rowe, Jr. wrote:
> >>Dumb Q perhaps; for APR-UTIL 1.0 don't we want to change:
> >>
> >>typedef struct apr_bucket apr_bucket;
> >>typedef struct apr_bucket_brigade apr_bucket_brigade_t;
> >>etc
> >>
> >>to follow our convention:
> >>
> >>typedef struct apr_bucket_t a
On Mon, 29 Sep 2003, [UTF-8] Branko Ä^Libej wrote:
> >>Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
> >>Win32, Netware, FreeBSD, Linux, MVS and djgpp; no wonder there are
> >>dangling references to it in apr_pools.obj.
>
> Uh -- I said HEAD, not the 0.9 branch.
As a data
On Thu, 25 Sep 2003, Stas Bekman wrote:
> Hopefully this makes things less confusing.
>* use for their data. It is possible to accidentally overwrite
>* data by choosing a key that another part of the program is using
>* It is advised that steps are taken to ensure tha
On Wed, 17 Sep 2003, Paul Querna wrote:
> Balazs Mezodi mentioned this problem more than a week ago (
> http://marc.theaimsgroup.com/?l=apr-dev&m=106249161123522&w=2 ), but it hasn't
> been fixed.
>
> Its a trivial fix to check the return code of create_resource in
> reslist_acquire, but here is a
On Sun, 14 Sep 2003, Garrett Rooney wrote:
> I'd say that it should be documented to include any memory barriers that
> are needed, I mean that is a portability concern, and APR is a
> portability library. I see a lot of people assuming that the atomic API
> would take care of that for them anywa
On Fri, 12 Sep 2003, Sander Striker wrote:
> In the past we've worked on pluggable memory systems, but the
> performance penalty of our implementation was to high at the time.
> If you are interested in that part of history, search around in the
> mail archives for SMS, smart/stackable memory syst
On Sun, 7 Sep 2003, André Malo wrote:
> PING! Can someone please commit this. Neither 2.0.48 nor 2.1.0 tags won't
> compile without this patch on win32.
Done, thanks.
On Sun, 7 Sep 2003, jc wrote:
> Need a fake id to get into the nude bar? Come to www.fakeidman.org and I
> will point you in the right direction! Too young to get your girl drunk
I'm not entirely sure how this message got through to the list. Will
investigate.
--Cliff
On Thu, 4 Sep 2003, Chris Fallin wrote:
> In order to prevent leaks each thread gets its own subpool, which it
> frees on exit. However, I see in apr_thread_create (at
> threadproc/unix/thread.c:160) that a subpool is allocated from the pool
> passed to the function. This pool is the one that is d
On Thu, 4 Sep 2003, Jeff Trawick wrote:
> comments?
+1.
> (hopefully you can cvs rm on the main branch and it still shows up in
> the 0.9 branch :) )
Yes, indeed you can.
On Wed, 3 Sep 2003, Jeff Trawick wrote:
> I'm through grepping for "deprecated" for the time being, so somebody
> else feel free to jump in ;)
Thanks Jeff!!
On Tue, 2 Sep 2003, Stas Bekman wrote:
> 3) there is no apr_file_tell
> http://marc.theaimsgroup.com/?t=10074811064&r=1&w=2
You don't need one. Just as there is an lseek() but no ltell(), you can
do:
apr_off_t offs = 0;
apr_file_seek(fd, APR_CUR, &offs);
at which point offs will ha
On Tue, 2 Sep 2003, Jean-Jacques Clar wrote:
> In the case that a server is running out of memory (yeah, I know it
> never happens), apr_allocator_alloc() is returning NULL, but it is never
> checked for in apr_bucket_alloc(). Does the bucket alloc function should
> pass that NULL back to the func
On Tue, 2 Sep 2003, Jeff Trawick wrote:
> somebody want to sanity check this before I screw everything up?
>
> $ cd apr
> $ cvs tag -b -r HEAD -R APR_0_9_X
> $ cd ../apr-util
> $ cvs tag -b -r HEAD -R APR_0_9_X
Looks basically right to me. Nits: If you're already up-to-date with
HEAD, you don't
On Tue, 2 Sep 2003, Balazs Mezodi wrote:
> i'm new to apr, so i don't know if i ask this question at the right
> place...
Indeed it is.
> how to use apr_reslist with sockets correctly? sockets are "fragile",
> therefore error handling is very important:
Hah, that's a good question. As far
What are people's feelings about apr_file_namedpipe_create()? It is only
implemented on Unix. OS/2 and Netware have "implementations", but only in
the sense that the function exists. It returns APR_ENOTIMPL. Win32
doesn't even seem to have that much.
Sander tells me that Win32 actually does h
On Sun, 31 Aug 2003, Justin Erenkrantz wrote:
> [X] - Yes, I think we're ready for 1.0 now (in both apr and apr-util)
> [ ] - No, I think we're not ready for 1.0 because __
On Wed, 13 Aug 2003, Jeff Trawick wrote:
> Cliff Woolley wrote:
> > Any objections to the following patch? All you do is pass
> > -DAPR_BUCKET_DEBUG to ./configure and then several things happen:
>
> is --enable-bucket-debug preferable? a couple of positive aspects of that:
On Wed, 20 Aug 2003, Jeff Trawick wrote:
> ain't none
>
> do you want a piece of code called every so often or do you want to
> unblock some call after a period of inactivity?
There's this library called lp_solve (which solves linear programs) I'm
using that, every once in a while, will go into a
I was hoping there would be some kind of APR equivalent of alarm(2), but
there's not. Nor can I find any Win32 equivalent. Anybody know what it
is?
--Cliff
On Thu, 14 Aug 2003 [EMAIL PROTECTED] wrote:
> > Sure... take a look at apr_os_file_get() which is declared in
> > apr_portable.h
>
> This answer is, I'm surmising, unfortunately incomplete. That is, on
> Unix systems, apr_os_file_get() will do the trick, but the OS file
> descriptor mechanism on
On Thu, 14 Aug 2003, Bojan Smojver wrote:
> I'm not sure if this list is the correct place to ask this question,
> given it's the APR development list, but I'll take my chances...
Definitely the right place. :)
> I'm trying to figure out how to get a file descriptor (integer or FILE*)
> out of
On Wed, 13 Aug 2003, Jean-Jacques Clar wrote:
> Am I missing something in the patch I have?
> I don't find the implementation of the two APR_RING_CHECK macros.
cvs up. :)
On Wed, 13 Aug 2003, Sander Striker wrote:
> > compiler command lines even longer
> >
> > more work though :)
>
> You can probably reuse what I did with --enable-pool-debug in APR.
Aww crap, now I gotta figure out autoconf? :-) Sure, that sounds
like a reasonable request.
--Cliff
On Tue, 12 Aug 2003, Greg Stein wrote:
> > +while (curr) {
> > +if (node == curr) {
> > +return 0;
> > +}
> > +curr = curr->next;
> > +}
> > +return 1;
>
> Forget the return code. Just stick an abort() in here.
return 0 to pop the assert, abort, sam
Any objections to the following patch? All you do is pass
-DAPR_BUCKET_DEBUG to ./configure and then several things happen:
1) the brigades get checked for consistency at various strategic points
2) and apr_bucket_free() calls are checked for double-free conditions
(eg, you destroyed th
I told this guy to subscribe to the list but I dunno if he did or not.
Please cc: him in responses.
--Cliff
-- Forwarded message --
Date: Sat, 2 Aug 2003 17:33:23 -0300 (ART)
From: Cristiano Maciel da Silva <[EMAIL PROTECTED]>
To: Cliff Woolley <[EMAIL PROTECTED]
On Fri, 18 Jul 2003 [EMAIL PROTECTED] wrote:
> ===
> RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v
> retrieving revision 1.196
> retrieving revision 1.197
> diff -u -r1.196 -r1.197
> --- apr_pools.c 28 May 2003 04:
On Fri, 18 Jul 2003, Brad Nicholes wrote:
> more threads could overwrite parent->child simply because the wrong
> mutex was locked or no mutex was locked at all (in our case). The call
> to apr_allocator_mutex_get() should use "parent->allocator" not
> "allocator". If you look at apr_pool_destro
On Fri, 18 Jul 2003, Brad Nicholes wrote:
>Under what circumstances would you want to create an allocator
> without a mutex assigned to it? We have been running into a problem
> with the NetWare MPM on multi-processor boxes where Apache faults
> periodically while trying to destroy the memory
On Thu, 10 Jul 2003, Joshua Moore-Oliva wrote:
> Regardless of it's usefulness, it is something that people can do. I do not
> see any performance penalty by running the cleanups before clearing the
> subpools, and it eliminates a possible segmentation fault.
Actually it would cause a lot more s
On Thu, 10 Jul 2003, Joshua Moore-Oliva wrote:
> This code here Fixed the problem by running the cleanups first then destroying
> the subpools.
>
> run_cleanups(&pool->cleanups);
>
> while (pool->child)
> apr_pool_destroy(pool->child);
-1 .. the order is correct as-is by design, I p
On Tue, 8 Jul 2003, [UTF-8] Branko Ä^Libej wrote:
> And a symbol that's not defined is treated as if it were zero by the C
> preprocessor. So it comes to the same thing in the end. :-)
I know it is on gcc, but I didn't know if you could count on that being
the case portably. If so, great! :)
-
On Tue, 8 Jul 2003, Ben Collins-Sussman wrote:
> Um, actually, apr_private.h.in isn't under version control. It's
> auto-generated by 'autoheader', which reads configure.in. That stuff
> automatically appeared when I added AC_CHECK_FUNCS(utimes utime).
Oops. :)
On Tue, 8 Jul 2003, [UTF-8] Branko Ä^Libej wrote:
> on those defines, giving utimes (which has the more precise interface)
> priority; e.g.,
>
> #if HAVE_UTIMES
> ...use utimes...
> #elif HAVE_UTIME
IIRC, that should be:
#ifdef HAVE_UTIMES
...use utimes...
#elif defined(HAVE_UTIME)
On Fri, 4 Jul 2003, Mark Jones wrote:
> I am thinking about using APR in a project. Are there any source for good
> example code using APR I have seen a few examples but all of them only seem
> to show the use of sockets with APR. I am very intersted in what APR can do
> on the multithread/proces
On Fri, 4 Jul 2003, [UTF-8] Branko Ä^Libej wrote:
> How? These flags are only used within APR, and are not even visible
> outside APR.
Oh? My fault, I'm sorry. I misread the fact that they had an APR_
namespace prefix as meaning that they were in the public headers and
didn't pay attention to w
On Fri, 4 Jul 2003, [UTF-8] Branko Ä^Libej wrote:
> /* Internal Flags for apr_file_open */
> -#define APR_OPENINFO 0x4000/* Open without READ or WRITE access */
> -#define APR_OPENLINK 0x2000/* Open a link itself, if supported */
> -#define APR_READCONTROL 0x1000/* Read the f
On Wed, 2 Jul 2003, Ben Collins-Sussman wrote:
> Subversion is already using apr_stat() to read the mtime of a file.
> But now we'd like to be able to *write* timestamps as well.
> Has this conversation been had before?
I did some digging on marc.theaimsgroup and found this:
http://marc.theaimsg
On Tue, 1 Jul 2003, Greg Stein wrote:
> Eh? Why the flag? What is that for... doesn't the caller know when and if he
> should clean up? So there shouldn't be a need for a flag...
The caller knows. But right now apr_buckets_alloc.c:alloc_cleanup() calls
apr_allocator_destroy(allocator) regardless
On Wed, 2 Jul 2003 [EMAIL PROTECTED] wrote:
> jwoolley2003/07/01 22:25:44
>
> Modified:buckets apr_buckets_alloc.c
>include apr_buckets.h
> Log:
> an addition to the api to allow httpd mpm's to share an apr_allocator_t
> between a thread pool and the thread's buck
On Thu, 26 Jun 2003, Jean-Jacques Clar wrote:
> I will really love to see the implementation of the
> apr_bucket_alloc_create_ex() taking an actual allocator as a parameter
> and setting the max_free limit on it before releasing 1.0.
I implemented it on Tuesday and need to test... planning on do
> So, no real reason other than no one has time... -- justin
Tell me about it. Grad school didn't used to be this busy... but they
sure are keeping me on my toes this year! Sheesh! :)
What are the real issues stopping us from releasing APR 1.0? (Yes, I've
read the STATUS file.) We've been "pushing toward" 1.0 for almost a year
now...
--Cliff
On Tue, 24 Jun 2003, Joe Schaefer wrote:
> However, I can see the value in not changing the current semantics
> if people are concerned that the change may cause problems for third
> party modules that rely on the current behavior. Either way, it's good
> to discuss this issue before adopting the
On Mon, 23 Jun 2003, Joe Schaefer wrote:
> OK. I've looked into the test failures, and it looks to
> me like the cause is a semantic change in apr_table_mergen.
> With the callback API, apr_table_merge with preexisting headers
> will merge *all* of them into a single header, whereas the
> current
On Tue, 17 Jun 2003, Max Bowsher wrote:
> Am I doing something wrong?
No, nothing wrong... the only problem is that there are a limited number
of people who deeply grok our build system (I am not one of them), and all
of us stay pretty busy most of the time. I've personally got about three
patch
On Sat, 14 Jun 2003, Joshua Moore-Oliva wrote:
> the offending part being
>
> * @param ch The character to write.
> * @param thefile The file descriptor to write to
>
> for GETc
Committed. Thanks!
--Cliff
On Fri, 13 Jun 2003, Joshua Moore-Oliva wrote:
> WIll 0.9.3 be considered to be out of alpha when it is released?
>
> I've been watching this project with great interest for quite a while, thogh
> I'm a little scared to use alpha code.
There's no particular reason for it to be called alpha except
On Thu, 5 Jun 2003 [EMAIL PROTECTED] wrote:
> -
> - The mission of the Apache Portable Runtime (APR) is to provide
> - a free library of C data structures and routines, forming a
> - system portability layer to as many operating systems as
> - possible, including Un
On Wed, 4 Jun 2003, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> If I understand you correctly, libraries should return the errno (because
> errors may mean strings also), and not try writing anything to stderr. The
> application should do the job of writing to stderr.
>
> Is that just your o
On Thu, 29 May 2003, [ISO-8859-1] André Malo wrote:
> configured with worker MPM.
> apr_md5.c:688: warning: `crypt_mutex_lock' defined but not used
> apr_md5.c:693: warning: `crypt_mutex_unlock' defined but not used
I was seeing the same thing on rh80 during 2.0.46 release testing, but
deemed it
On Fri, 9 May 2003, Sumesh T.A wrote:
> hi i am working with JXTA-C. i am missing the file jpr/jpr_types.h.
> where can i find jpr/jpr_types.h. if you have this file please send
> me.its very urgent
Hi...
The APR project doesn't have anything to do with JXTA, so we're
unfortunately unable to
The humor of the version number "apr 1" just now struck me. ;)
On Sun, 23 Mar 2003, Craig Rodrigues wrote:
> But it exists in the APR codebase,
I don't count that as making it necessarily correct. :) But even if it
is correct on Netware, that doesn't make it correct on FreeBSD. And I'm
pretty sure it's not.
--Cliff
On Sat, 22 Mar 2003, Craig Rodrigues wrote:
> +#define apr_atomic_set(mem, val) (*(mem) = val)
> #define apr_atomic_read(mem) (*mem)
> +
> +#define APR_OVERRIDE_ATOMIC_DEC 1
> +APR_INLINE int apr_atomic_dec(apr_atomic_t *mem)
> +{
> +atomic_subtract_int(mem,1);
> +return *mem;
On Tue, 11 Mar 2003, Ben Collins-Sussman wrote:
> Shouldn't apr_generate_random_bytes() being using /dev/urandom instead?
> According to thom, ./configure picks up 'random' before 'urandom', and
> substitutes whichever it finds first. I think this is a Bad Thing.
> urandom should be preferred, no
On Tue, 11 Mar 2003, Robert E. Gruber wrote:
> I'm using apr and apr-util for a new project. I cannot figure out what
> the rules are for how threads, thread lifetimes, and pool create/destroy
> interact.
>
> For example, can thread X create a subpool S and another thread Y
> destroy S? Does thr
On Thu, 6 Mar 2003, Sander Striker wrote:
> I think they are. There is no mmaping taking place when filelength <
> APR_MMAP_THRESHOLD, which is at least 1:
Oh right! I forgot about that feature. :) It's all good.
--Cliff
On Fri, 28 Feb 2003, William A. Rowe, Jr. wrote:
> Short of turning on largefile support here and now, what about a simple
> APR hack? Keep an overflow flag for apr_dir_t, and when the lstat()
> call from apr_dir_read returns EOVERFLOW, set that flag but loop and
> grab the next legal file.
Work
On Fri, 28 Feb 2003, Sander Striker wrote:
> Can someone at home in the file buckets take a look at these:
>
> buckets/apr_buckets_file.c:93:if (apr_mmap_create(&mm, a->fd,
> fileoffset, APR_MMAP_LIMIT,
> buckets/apr_buckets_file.c:102: (apr_mmap_create(&mm, a->fd,
> fileoffs
On Thu, 27 Feb 2003, Sander Striker wrote:
> #else
> -rv = munmap(mm->mm, mm->size);
> +if (mm->mm != NULL)
> + rv = munmap(mm->mm, mm->size);
> +else
> + rv = APR_SUCCESS;
Wouldn't it be better to check mmap()'s return value in apr_mmap_create()
and have it return an error
On Wed, 26 Feb 2003, William A. Rowe, Jr. wrote:
> an APR version test for 0.9.2 because we've defined the version as 0.9.2
> (-dev)
> for a very long time.
> It seems that this should become the 0.9.3 release. Can everyone else
> accept that numbering?
+1
On Tue, 18 Feb 2003, [UTF-8] Branko Čibej wrote:
> It's fairly portable on most every Unix variant. It just so happens that
> APR isn't about portability across Unixes, so we really should have
> wrappers. We have apr_os_thread_current, so we should also have an
> apr_os_proc_current.
Of course w
On Fri, 14 Feb 2003, Dagfinn Aarvaag wrote:
> When creating TCP connections the client leaks memory, 8/16 kbyte, for
> every connection that is created. The server side does not leak.
Which client?? Which server?
--Cliff
On Fri, 14 Feb 2003, [UTF-8] Branko Čibej wrote:
> Excuse me? your compiler is broken. A function definition is a
> prototype, so you don't need an extra prototype in this case. But I
> agree that the prototypse should live in a better place.
gcc -Wstrict-prototypes causes this. We look for thes
On Tue, 4 Feb 2003, Jeff Trawick wrote:
> get over it already :) try your hand at some deep breakage that won't
> be noticed for a while
/me takes a deep bow. :-)
;)
On 4 Feb 2003, Philippe M. Chiasson wrote:
> Ideally, I would initially package datagram-buckets with mod_udp itself.
> Just gotta figure out how to create my own bucket type.
It's no different than creating a bucket type in apr-util, really. Take a
look at the ERROR buckets that Apache defines
On Mon, 3 Feb 2003, Philippe M. Chiasson wrote:
> I've been working on mod_udp for the last week or so and got everything
> working in a modular way. It basically works fine.
Just one quick comment regarding the udp patches before I forget...
One of the patches modified socket buckets to add a c
On Thu, 30 Jan 2003, Garrett Rooney wrote:
> copying rules.mk along with the other files from apr seems like as good
> a plan as any, and it seems to work.
Do me a favor and post patches as type text/plain...
application/octet-stream doesn't get along with my mail client. :)
Thanks,
Cliff
On Thu, 23 Jan 2003, Jeff Trawick wrote:
> most but not all of the rest of APR does that
> the inconsistency is ugly, but being able to see EINTR is important
> functionality
MHO: Sounds like a job for an _ex() function... apr_proc_wait() should not
return EINTR. Another function with a similiar
On Thu, 23 Jan 2003, [UTF-8] Branko Čibej wrote:
> Not me. My changes don't contain tabs, the rest of the code does. Would
> you rather I did an M-x untabify before committing? :-)
Oh, oops, my bad. Didn't notice which way around it was. You did the
right thing then. :)
On 23 Jan 2003 [EMAIL PROTECTED] wrote:
>{
> char buffer[APR_PATH_MAX];
> +apr_pool_t *subpool;
> +apr_status_t status;
> char *ptr;
>
> +status = apr_pool_create(&subpool, ctx);
> +if (status)
> +return status;
> +
> if
On 7 Jan 2003 [EMAIL PROTECTED] wrote:
> Log:
> Finish off the rename of include/arch
>
>#include "apr_thread_proc.h"
> -#include "fileio.h"
> +#include "apr_arch_fileio.h"
While we're at it (yes Thom, I'm just trying to make more work for you
here ;), can we standardize the fileio vs
On Mon, 6 Jan 2003, Thom May wrote:
> Ok, so this looks like a rough consensus on apr_private_*.h, right?
> What's the best way to rename the files? cvs rm and add them again with new
cvs rm and add them again is what I'd say. There are several opinions
that come up any time we go through a file
On Sun, 5 Jan 2003, Greg Stein wrote:
> Drop the "private" part. They're already private based on where they're
> located, so there isn't a need to further qualify them. I'm also assuming
> that we can manage to avoid conflicts between the arch-specific and the
> public file names (since we manage
On Fri, 20 Dec 2002 [EMAIL PROTECTED] wrote:
> apr_brigade_create(bb, ...);
> fill_brigade_with_data(bb, ...);
> ap_pass_brigade(bb, ...)
>
> ap_clean_brigade(bb, ...);
> fill_brigade_with_more_data(bb, ...);
> ap_pass_brigade(bb, ...);
>
> This is perfectly legal for a handler to do.
No it isn't
On Wed, 11 Dec 2002, Graham Leggett wrote:
> I would like to make it possible for a site to be accessible without
> password if originating from a specific IP address range, and for the
> site to require a password otherwise.
Sure, it's been possible for a long time. See the "Satisfy any"
direct
101 - 200 of 729 matches
Mail list logo
