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 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
The humor of the version number "apr 1" just now struck me. ;)
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
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 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, 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 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 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 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 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, 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
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
> 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! :)
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
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 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, 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 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 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, 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 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 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:
> 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 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 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 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 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 [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:
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]
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
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
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 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 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 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
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 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
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 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 __
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 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
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, 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, 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 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 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 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 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 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 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, 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 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 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 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 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 Tue, 7 Oct 2003, William A. Rowe, Jr. wrote:
> Perhaps apr_brigade_t says it all...
+1.
> 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
I'm planning on rolling 0.9.5 and 1.0-pre1 tarballs tomorrow (Wednesday)
unless somebody has strenuous objections.
--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.
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 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 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, 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 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 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 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 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 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 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:
> 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 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, 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 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 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, 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 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. :-)
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, Donald Doane wrote:
> The following comment is from apr_lib.h:
>
> * apr_vformatter does not call out to any other code, it is entirely
> * self-contained. This allows the callers to do things which are
> * otherwise "unsafe". For example, apr_psprintf uses the "scratch"
>
On Sun, 11 Jan 2004, Charles Bonello wrote:
> I am a student studying business studies at school and I would like some
> information about APR. Would you please forward some information.
Have you seen our website at http://apr.apache.org/ ? What additional
information would you like to know?
--
On Mon, 12 Jan 2004, Craig Rodrigues wrote:
> Has anyone made a move at releasing apr-0.9.5?
> I have a lot of FreeBSD users asking me for an apr-0.9.5
> release so that it can be added to the FreeBSD ports
> tree.
Arhhh.. yet another thing on my list of things to do yesterday. :-/
I'll atte
On Mon, 23 Feb 2004, Scott Lamb wrote:
> significant difference between them. In transferring either big or
> small files with httpd-2.0 HEAD and ab over loopback on Darwin
> (keepalive on). Which I'd think would be the ideal situation for seeing
> an improvement...
Neither ab nor loopback make f
On Mon, 23 Feb 2004, Justin Erenkrantz wrote:
> Well, if we believe the AL v2.0 is GPL-compatible, then this is a moot point,
> I believe.
"GPL-compatible" means that Apache-licensed code can be added to a GPL
product and that that product can still be distributed under the GPL, not
the other way
On Tue, 24 Feb 2004, Sander Striker wrote:
> This would make the use of any OS header files a derived work of the OS,
> I can't imagine you think this is the case.
Not a good example; there's a specific exemption for that case IIRC.
--Cliff
On Tue, 24 Feb 2004, David Reid wrote:
> +1 Can we make this a priority for the PMC Chair to persue with the
> board?
I would, but the board (or rather Greg) is already on it. :)
> Given that SVN is now 1.0 we should really get our asses in gear and get 1.0
> out the door. Given the strong opin
On Sun, 29 Feb 2004 [EMAIL PROTECTED] wrote:
> I've been lurking for the last few days, and this list is too quiet. :-) I'd
> like to stir up trouble again, so I am officially asking to have my commit
> access re-instated. I am in the middle of creating a new project that uses
> APR,
> and I w
I wanted to do this before I left for NY, but alas, time ran out. I'll
get back Wednesday night, so I'll do it then. If you want to get
something in before the T&R, here's your chance. :) I'll also resurrect
the 1_0_BRANCH at that time, and then -dev will be 1.1-dev, hoping to get
1.0 out SOON
On Fri, 12 Mar 2004, Craig Rodrigues wrote:
> What's the status of apr 0.9.5? I'm getting many
> requests to update apr in the FreeBSD ports system.
T&R tomorrow.
I'll try to attend to any outstanding patches before I roll the RC.
--Cliff
On Sun, 14 Mar 2004, Guenter Knauf wrote:
> For what is it good for that I'm familiar with CVS, have it on my
> machine, and am able to contribute patches, if I'm not able to commit
> them, and my posts get mostly ignored (as with many other posts too)
> because either the commiters have no time f
On Sun, 14 Mar 2004, Cliff Woolley wrote:
> I'll put my heads together with the PMC and see what we can come up
> with.
Umm... just reread that... "my heads"... *crosses all (four? eight? ;)
eyes*... okay... I need a vacation ;)
On Sun, 14 Mar 2004 [EMAIL PROTECTED] wrote:
> This needs to get resolved. I believe the fix is to simply add the correct
> checks to APR_STATUS_IS_TIMEUP, but I also would like to know if we really
> need
> to keep APR_STATUS_IS_ETIMEDOUT at all. Can we mark it deprecated?
+1 as far as I'm co
I know it's got a few more patches I need to get in before it's ready to
go, but just so that I could go ahead and at least get started on this
(using some extended definition of "tomorrow" which technically ended
about 24 hrs ago, sigh)... I've tagged apr, apr-util, and apr-iconv as
JCW_0_9_5_PRE
On Mon, 15 Mar 2004, Geoffrey Young wrote:
> if you could take a look at this
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25550
Noted, thanks!
On Wed, 17 Mar 2004, Sander Striker wrote:
> > 1.20.2.3 +1 -1 apr-util/misc/apr_rmm.c
> > 1.3.2.2 +10 -2 apr-util/test/testrmm.c
> >
> > Sander and company - if the final tags of apr 0.9.5 / httpd 2.0.49 can
> > pick this up - it would be lovely. Well validated.
I'll make sure they
On Wed, 24 Mar 2004, Marc M. Adkins wrote:
> PS Is there a mail archive for this list?
Well I can at least answer this half. ;) Yes, there are several.
Here are a few web-based ones:
http://marc.theaimsgroup.com/?l=apr-dev&r=1&w=2
http://nagoya.apache.org/eyebrowse/SummarizeList?listId=183
-
On Mon, 19 Apr 2004, Mathihalli, Madhusudan wrote:
> Since a lot of the async signals are blocked by default, I thought
> it'll be good to provide a apr_(un)block_signal() api for those who want
> to block/unblock only select signals. Here's a patch to do that.
Is this portable? (Admitting
On Tue, 20 Apr 2004, Mathihalli, Madhusudan wrote:
> Since I didn't get any negative feedback, can I take that it's okay to
> commit the change ?
Lazy consensus would seem to apply -- so, yes. :)
On Fri, 14 May 2004, Stas Bekman wrote:
> So, who changed that in 2.0.49? It worked just fine pre-2.0.48. The guilty
> party please stand up and explain. This change causes a serious breakage in
> the protocol handlers and filters on those affected platforms. I suppose apr
> doesn't have tests for
On Sun, 16 May 2004, Stas Bekman wrote:
> What I'm after is having APR API specify which apr functions have errno set,
> so one can rely on that and not do guessing which can change in the future.
My gut reaction is that if we actually /need/ errno to be set to glean
useful information about what
On Mon, 17 May 2004, Joe Orton wrote:
> I'd hoped some friendly buckets guru would step in here :) I guess if
> it's correct to solve this at bucket-level, the solution is to make
> socket_bucket_read() check whether the socket is non-blocking on each
> call, and temporarily set the timeout to -1
401 - 500 of 729 matches
Mail list logo
