g the code.
david
> [EMAIL PROTECTED] wrote:
>
> >I believe this is a bug. However, we have never been able to reliably
fix
> >it. You should check the APR list archives, because David Reid and I
> >discussed this a while back. It was probably around March of this year.
I've reviewed the code and can't quite see what you mean...
> >I believe this is a bug. However, we have never been able to reliably
fix
> >it. You should check the APR list archives, because David Reid and I
> >discussed this a while back. It was probably around
OK, well I'll try to add some stuff to this discussion...
Last night I tried to get sms looking and acting as pools Basically I added
some stuff and munged my tree so that when apr_pool calls were made they
were answered in sms code. This is configurable via an --enable-sms switch
to configure.
What's with the HTML email????
> David Reid wrote:
>
> >OK, basically apr_implode_time ONLY works with an apr_exploded_time_t.
We
> >have a number of ways of getting one of those,
> >
> >/**
> > * convert a time to its human readable components using an
> Hi Ian,
>
> > I'm in the middle of writing a pool-tester
> > which can take a file and pool allocation commands
> > (alloc/create/destroy/etc)
> > and replay them.
> > combine this with some threads, and a capture tool in the current pool
> > code and we should be able to test different pooling a
The problem with the static structure is that we loose the ability to have
default allocators available and would have made no difference at all in
this case as the lock creation is a different problem. We'd still do the
creation as
- calloc the memory
- do the first part of the initialisation
-
> Ian Holsman at [EMAIL PROTECTED] wrote:
>
> > On 29 Jun 2001 11:53:47 -0700, Kevin Pilch-Bisson wrote:
> >> On Fri, Jun 29, 2001 at 10:28:46AM -0700, Justin Erenkrantz wrote:
> >>> I guess I'd see what Subversion does - do they
> >>> require an "installed" APR, or do they ask for the location of
> On Sat, Jun 30, 2001 at 12:20:31AM +0100, David Reid wrote:
> > Why? If we have shared libraries available can't it just use those? I
mean
> > at present I'm not sure apache can, so this whole area needs some
looking at
> > yet.
>
> The constant problem on
> > I think with the testmem and Ian's testpool, I think we are close to
> > having a decent testing environment that is outside of the "real"
> > world. The only thing I'm waiting on now is David's implementation of
> > apr_pool_t as a SMS. =)
OK, OK, it's on it's way :) Patience is a virt
In the recent discussions about implode/explode time it became obvious that
the documentation (such as it is) isn't very clear on why we do things the
way we do... This I will attempt to solve by this email.
We wrote the apr_implode_time routine to take an exploded time structure
(that is an APR
Anyone have objections to moving the apr_pools.c file into the
memory/unix directory?
This will mean that all the memory code is in one place and we don't
build anything in the lib directory anymore so it can be removed from
our build in configure.in. It also allows us to do the sms == pools a
lo
> hiya david,
>
> i just want to double-check something. i got caught out by
> creating cookies of 1 year which actually turned into 30 seconds
> because apr_time_t is in microseconds :) :)
>
> so, could you confirm at the points below for me? thanks
>
> also, i should point out some experience
OK, to comment on this prior to the patch being posted...
I have SMS running as pools and the implementation I have manages to run the
server at 80% of the speed of pools. This is with no changes to the httpd
code except using --enable-sms on the configure line. Now, this isn't
amazing, but does
Justin Erenkrantz wrote:
> On Sat, Jul 07, 2001 at 06:42:24AM -, [EMAIL PROTECTED] wrote:
> > BTW, do we still need to add the @deffunc lines as we don't seem to
> > have been doing in some places. Is this a scandoc change Ben?
>
> Ben's gone on record saying we don't use scandoc anymore,
Guys,
I'm going to try and add a configure option to allow us to add Electric Fence
support to apache, but will it be useful for APR as well? It's a simple
enough patch as I'm not planning on much autodetection, simply having the user
identify where it is and have a couple of the more common loca
Folks,
Well, here is the patch that I promised a while back. It basically adds
wrappers so that pools are implemented as SMS.
Basically we add a new file, apr_sms_pools.c, add the configure switch
--enable-sms to switch this mode on and move some stuff around in
apr_pools.h to make the wrapping
> > 1. The good news is that allocations of small amounts
> >of memory are very efficient. They almost always
> >take the fastest path through the code, in which
> >some available space is reserved from the
> >"sms->used_sentinel.prev" block with a handful of
> >pointer arithme
To be honest changing sms_trivial to use malloc instead of apr_sms_malloc is
an easy move (just a few lines to change) so it's probably worth trying and
then seeing what we get...
BTW, I'm impressed by the amount of traffic this has generated. Exactly
what I hoped it would do!
I guess also I'm w
OK, so yesterday I went "tubing" and didn't even open my computer, so today
when I looked at 100 or so messages and tried to get up to speed, I was a
bit surprised to find the message subjects weren't useful.
I'm probably as guilty as anyone but can we all try to keep message subjects
relevant and
OK, so I've had a couple of +1's for applying the patch, and 2.20 has been
released, so anyone object if I do it now?
david
Why do we still have the apr_signal.c file in lib? We don't seem to be
building it anymore so can it be removed as well? If so I'll also
remove the Makefile.in as we're not doing anything in the lib directory
anymore.
david
Well, have you looked at the patch? It doesn't change anything unless you turn
on a switch in sms.
However, I'll hold off...
Thought the new business of tagging/rolling was supposed to get rid of all this
bu**s**t?
david
Cliff Woolley wrote:
> On Tue, 10 Jul 2001, David Reid wr
uld only be holding up developers if we
> are absolutely sure we are about to get a good build.
>
> Ryan
>
> On Tue, 10 Jul 2001, David Reid wrote:
>
> > Well, have you looked at the patch? It doesn't change anything unless you
> > turn
> > on a switch in
Ah yes, you're quite right and it shouldn't be there...that's the next
debugging type bit I have to add...
Apologies. Thought I'd removed them all.
david
- Original Message -
From: "Greg Ames" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, July 11, 2001 7:04 PM
Subject: Re: cvs commit: apr/in
What does this have to with lib/apr-signal.c
Come on guys, change the subject if you're changing the topic...
david
> On Thu, Jul 12, 2001 at 12:47:13PM +0200, Sander Striker wrote:
> > [...]
> > > what i suspect is happening in subversion [correct me if i'm
> > > wrong, here!] is that they
If all the SMS's do this, i.e. it's done in the framework not in the
specific SMS, then we will have a very nice locking strategy :)
> > Basically I wanted to do locking on demand (so when 2 or more threads
> > are using a sms it locks, when only 1 thread uses it, it doesn't
(default)).
> > Maybe
Yeah, just commit it with the #ifdef's...
david
> On Thu, Jul 12, 2001 at 04:11:25PM +0200, Sander Striker wrote:
> > PS. I want to commit apr_threads_sms, but I don't know how to build
> > it conditionally. I could ofcourse just put #if APR_HAS_THREADS
> > #endif around all the code in
eing proposed
> > involve pools and threads.
> >
> > well, surely those two could be tested and developed at the
> > same time, yes?
>
> Part of the problem is that two of the people working on this don't
> have commit access to httpd. David Reid does. I imagine th
Just to let folks know, I'm off to Havana tomorrow afternoon for a few days
(back Wednesday) and won't be in contact at all! Yes, I'm not even taking
my laptop :)
When I get back I'll try to catch up, but have my 6 monthly check over the
weekend so will be distracted until at least Sunday afterno
> > It appears to me that APR threads (on unix) are automatically creating a
> > subpool, and then later destroying it only if/when apr_thread_exit() is
> > explicitly called. I have a few questions about
threadproc/unix/thread.c:
> >
> > 1) How do we guarantee the child-pool is being destroyed? Wh
> On Wed, Jul 18, 2001 at 11:02:27AM -0500, William A. Rowe, Jr. wrote:
> > > And enforcing that the 'allocation' pool is either top-level itself,
or a
> > > descendant of the 'scope' pool, assures that the cleanups will unwind
> > > properly for both (since this thread-child pool is torn down,
eve
OK, so strange question for those of you who know...
FreeBSD 4.3, when I use gcc -pg I get full profiles, but that includes
system level functions, so when I try to look at how apr_blah is doing I
don't see it but rather the calls within the function, which may be useful
in more detailed profilin
Just a quick question, but I'm seeing one of the apache worker threads
getting stuck in apr_pool_clear, chewing resources and basically being
a PITA. The thread keeps looping in
while (a->sub_pools) {
apr_pool_destroy(a->sub_pools);
}
This happens when I've served a randon numb
We do use getservbyname and I wondered about that today as well... Also the
gethostbyname_r on beos is broken in the current version (segfaults) but
gethostbyname is thread safe so what's the best way of doing that - hints
file?
david
- Original Message -
From: "Jeff Trawick" <[EMAIL PROT
The malloc_debug stuff on beos really needs to also remove the -O2 flag from
the build line or it really does take a VERY long time a huge amount of
memory to build, so autoconf-guru like people, is it possible that we can
add a function such as APR_REMOVEFROM that does exactly what it sounds like?
This basically does what it says...
david
Index: apr_common.m4
===
RCS file: /home/cvs/apr/build/apr_common.m4,v
retrieving revision 1.20
diff -u -r1.20 apr_common.m4
--- apr_common.m4 2001/07/05 00:02:10 1.20
+++ apr_commo
t;network_io/beos sendrecv.c
> Log:
> Couple of fixes for pre-BONE beos...
> - correctly set the file_as_socket
> - add the apr_wait_for_timeout so it's visible
>
> These come from Brad Froehle.
>
> Submitted by: Brad Froehle <[EMAIL PROTECT
Guys,
If nothing else this discussion and the work done has demonstrated that the
pools code is actually pretty damn good for what we're doing with it in
apache. The SMS code has uses, but they're probably not going to be in
replacing pools as the basic, underlying memory allocation system in APR
Bill,
Did you look at the "other" wrapper header file we'd had in the test
directory for about 3 months???
Why o why do we keep re-inventing stuff???
david
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 27, 2001 6:40 PM
Subject: cvs commit: apr
cvs update -dP
make distclean
./buildconf
This is the result on beos...
$ ./buildconf
rebuilding srclib/apr/configure
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: libtool version 1.3.5 (ok)
Copying libtool helper files ...
Creating include/arch/unix/apr_pri
Justin was spot on, removing srclib/apr-util/aclocal.m4 got a clean
build.
As I've been playing with several libtools how about we remove the
aclocal.m4's whenever we run buildconf so we always generate them?
david
So I got a configure complete and make managed to get to dbm in apr-
util before it barfs. Looks like the dbm slection isn't being made for
some reason...
/bin/sh /boot/home/httpd-2.0/srclib/apr/libtool --silent --mode=compile
gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-
OK, so how about we remove it during the buildconf stage - which is what I
mean to say and for some reason didn't...
:)
david
> On 30 Jul 2001, Ian Holsman wrote:
>
> > should we add this aclocal.m4 to the 'make distclean' target ?
>
> I don't think so...
>
> "make distclean" should leave you
Folks,
The httpd guys have started adding the code that uses pthread conditionals,
but we did talk about possibly adding it to APR. So, what do we think?
I guess what we're talking about is
apr_cond_t
apr_cond_create
apr_cond_signal
apr_cond_broadcast
apr_cond_wait
apr_cond_destroy
I know i
What follows is a profile for beos bone running 1000 connections using
a single thread (-DONE_PROCESS). Columns are
no. of calls
time in calls
time incl sub calls
function name
Raises some interesting questions, like how many times do we call
ap_palloc/ap_pcalloc/lock/unlock and stat for 1000
Marc was right about the multi-language thing... Howvere, here are some
more results to ponder..
Did a profile run of 1000 and 2000 against a new copy of index.html.en in a
seperate directory and renamed to simply index.html. Both runs used a
single process and a single thread...
Results are fo
Sorry to be coming so late to this, but why have we switched to building
apr-util first? This seems to be ass backwards as apr-util is a utility
library built on top of apr and also means we can't build on beos :(
david
+1 from me.
(No offence taken :))
david
> [This is not directed at you David. Your patch reminded me that we
> have this problem everywhere.]
>
>
> On Tue, Sep 11, 2001 at 01:33:39PM -, [EMAIL PROTECTED] wrote:
> >APR_DECLARE(apr_status_t) apr_thread_exit(apr_thread_t *thd,
apr_status_t
> Right now we are trapping EACCESS and moving it to 'EAGAIN' for a flock().
>
> But on some platforms you can get things like EWOULDBLOCK and EINTR too.
>
> In APR is there a convenient macro to figure out if the exit code is a
> 'hard' error (say EINVAL, EBADF, ENOTSUPP) or one to figure out if i
This first patch looks right but I haven't got a machine that uses poll to
test on, so I won't commit it. Jeff?
david
- Original Message -
From: <[EMAIL PROTECTED]>
To:
Sent: Monday, November 05, 2001 12:55 PM
Subject: [PATCH] apr_poll_socket_mask() bug fix (resubmit)
> Hi,
> I former
Trying to fix a bug in BeOS, I came across this...
Setting the pipe attributes by default sets the timeout to zero which in the
apr_file_pipe_timeout_set sets the pipe to non-blocking with a timeout of 0
(infinite timeout?). In this state EWOULDBLOCK is likely, but in
readwrite.c we check for thi
Did any of us ever get round to adding documentation (like proper
documentation, not inline) as to all the various options we've added for
debugging. profiling etc and advice on how to use them? I can't help
thinking it would be useful and ISTR we talked about it...
If not then maybe the time is
Anyone object if we move it into apr from apr-util? I ask as I'm using the
macros in the rewrite of my conditional code and the rings may be useful in
other places as well. APR seems like a better venue.
I guess if we do move the file, can someone with enough karma do it so we
preserve the histo
What about a similar thing to allow us to tag threads as well? the
information could be included when spewing out debug information and may be
useful.
Just a thought.
david
- Original Message -
From: "Jeff Trawick" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, December 18, 2001 5:01 PM
Subjec
Spoke to Cliff and he had no objections, so can someone with the karma move
the file (hopefully keeping the history) as no one else has spoken up with
an objection (has anyone else even thought about it??).
david
- Original Message -
From: "David Reid" <[EMAIL PROTECTED]&
Maybe the create could simply cache the exit code in case it's useful later?
david
- Original Message -
From: "Brian Havard" <[EMAIL PROTECTED]>
To: "APR developers"
Sent: Friday, December 28, 2001 1:04 AM
Subject: Re: cvs commit: apr/test testthread.c
> On Thu, 27 Dec 2001 15:53:44 -0
FreeBSD.
bash-2.04$ pwd
/usr/home/dreid/httpd-2.0/srclib/apr-util
bash-2.04$ ./buildconf
Creating include/private/apu_config.h ...
Creating configure ...
Invoking xml/expat/buildconf.sh ...
Incorporating /usr/local/share/aclocal/libtool.m4 into aclocal.m4 ...
Copying libtool helper files ...
Putti
The reason for the extra is that we measure in calls that will add time to
the sleep, hence the time measured is unlikely to be less...
david
- Original Message -
From: "Aaron Bannert" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, January 02, 2002 10:53 PM
Subject: Re: cvs commit: apr/test te
Looks OK to me as well.
david
- Original Message -
From: "Brian Pane" <[EMAIL PROTECTED]>
To: "Jon Travis" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, January 08, 2002 1:48 AM
Subject: Re: Time funniness between HPUX and everyone else
> Jon Travis wrote:
>
> >Ok, here's a small patch whic
Sorry, but I really don't like this patch.
The problem that we had wouldn't have been addressed by this patch anyways,
and we are a library - so why are we trying to tell users what they can and
can't do?
I'd like to revert this patch.
I think we should also have a _dup2 version of this function
But the patch didn't actually do anything to prevent the problem we saw as
it was in NO way related to a fork(). The issue is that if we call a
pool_clear we'll run the cleanup's anyway, as we should.
I think I'd be happier just letting the user decide and not getting all
motherly and trying to k
This patch basically adds apr_file_dup2 to APR and changes the logic such
that unless we call apr_file_dup2 we only ever call dup, not dup2.
This should prevent some potential errors and also follow the
posix standards closer.
It doesn't make any attempt to protect any fd's, which is how I
think
> > dreid 02/01/11 01:04:51
> >
> > Modified:include apr_file_io.h
> >file_io/unix filedup.c
> > Log:
> > Add apr_file_dup2.
> >
> > This has implications in that we now only do dup2 when we call
> > apr_file_dup2 and this will potentially cause problems for cod
I've been up all night so this may be off base...
AFAICR sockets using AF_UNIX are essentially local inter process
communication channels?
If this is the case then why are we having this discussion about adding more
to the network_io and not simply talking about adding an ipc_ set of
functions to
> David Reid wrote:
> >
> > I've been up all night so this may be off base...
> >
> > AFAICR sockets using AF_UNIX are essentially local inter process
> > communication channels?
>
> They are local sockets. The difference is a little like the difference
This was posted by Tom Lane on the Postgresql [patches] list, which I
thought might be of interest :)
The thing that sticks in my craw about OpenSSL's approach to this is
that they assume application programmers (or database interface library
programmers, in this case) know more about how to find
> > > Funny you should bring that up (and particularly that ipc_ prefix).
> > > Recently I've been working on a stream pipes proposal for APR that I
have
> > > yet to post. This is not quite the same as Unix Domain Sockets, so it
> > > wouldn't be usable for things like EGD, but would be useful for
Maybe you'd be so kind as to add testshm to the repository in that case??
david
> aaron 02/01/09 22:39:09
>
> Removed: test testshmem.c
> Log:
> Obsoleted by testshm.c (as the old apr_shmem_t API is removed and
replaced
> now with apr_shm_t).
>
Following on from Sander & Ian's work on adding debug code to the pools, is
there any reason this can't be extended across to APR in general? Jeff has
recently posted to httpd about a problem he's been having and has a patch
that he doesn't really want to go into APR for adding some interesting
de
I'm +1000 for a better way of dealing with "XML/XSL/whatever the hell we're
calling it that begins with an X this week" in C as Java suport isn't as
widespread as the java nuts (sorry Pier) would have you believe and I'm
happier with C for a lot of projects. Anythign we can do to help this,
let's
Yeah well, maybe if we'd actually paused an thought before jumping into the
GA we'd be in better shape rather than approaching SNAFU.
david
> -> This is quite an API change - soon after products
> which rely on it have gone GA. Which is a patent
> way to get breakage - and I seen o compelling nee
Can someone try this patch on such a system? I don't have access to one but
the patch looks OK on a brief inspection.
david
- Original Message -
From: "Joe Orton" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, May 08, 2002 10:30 AM
Subject: [PATCH] support $AUTOCONF and $AUTOHEADER
> This is
What was the problem in subversion?
Might as well know before going too much further...
david
> Due to some recent confusion with SVN and APR_STATUS_IS_SUCCESS,
> I'd like to consider removing this macro and just forcing
> everyone to do either a non-zero check or checking against the
> APR_SU
Agreed, it's premature.
There may have been volumes of discussion but little of it seems to have
addressed the problems.
Can someone simply restate what issue needs fixing. No more hand waving or
IRC chats, a simple email explaining the issue and what needs fixed.
david
> On Fri, Jul 12, 2002 a
+1 from me. Let's finish this nonsense!
david
> New proposal... leave apr_time_t exactly as it is. The performance
problem
> is with how we are converting an apr_time_t into a value with 1 second
> resolution (ie, doing 64 bit divisions). I propose we introduce some new
> macros (or functions)
Can we all come down off the ceiling for a bit and get our feet back on the
ground?
I can't help but wonder why we are making this whole thing so complicated
when people have been using computers and libraries using time quite happily
for a number of years without getting as involved as this has g
I'm -0 on adding them as they're really NOT portable. All the code I've seen
to add similar functionality on non-unix platforms has been flawed in a
number of ways and doesn't actuallt equal a 1 - to - 1 replacement for
AF_LOCAL.
One thing is for sure, they can't be added to apr_socket_t as that w
Yeah, but this is really the thin end of the wedge... :(
What's next? Given that we seem to be adding this because "it's easy on
unix" do we now have to start adding all the windows features we like? Oh
no, we're mainly unix folks aren't we? Sorry, but comments like this make me
verge more on the
New poll test works fine on beos and apache builds OK but ab -n1000 -c2
crashes with a segfault in apr_poll.
Off on hols so can't diagnose further - sorry.
david
- Original Message -
From: "Ryan Bloom" <[EMAIL PROTECTED]>
To: ; <[EMAIL PROTECTED]>
Sent: Friday, August 02, 2002 7:59 PM
Su
+1 on fixing both.
david
- Original Message -
From: <[EMAIL PROTECTED]>
To:
Sent: Thursday, August 22, 2002 8:07 PM
Subject: apr_snprintf not compliant
>
> apr_snprintf and apr_vsnprintf are not compliant with the POSIX snprint
> standard currently. There are two problems. 1) a leng
APU_
david
>
> Biggest problem is choosing between APRUTIL_ or APU_ for the
> version prefix. I'm waffling here. Any suggestions? -- justin
>
In my builds I'm still seeing this as part of the link line for libaprutil.
Any ideas why as we now have different library names don't we?
david
Not sure I like this. Shouldn't the other project just use the apr files
rather than copying their own versions?
More context please...
david
> Since we have a lot of files within APR that we want to share across
> other projects to help support the build system, I think we should
> create an ap
of doing it.
david
> David Reid wrote:
> > Not sure I like this. Shouldn't the other project just use the apr files
> > rather than copying their own versions?
> >
> > More context please...
>
> if the projects use the apr files, then you end up with the situation
for it to
all go bang.
david
- Original Message -
From: "Aaron Bannert" <[EMAIL PROTECTED]>
To: "APR Development List"
Sent: Friday, September 13, 2002 7:09 PM
Subject: Re: [PROPOSAL] Create apr-build repository
> On Fri, Sep 13, 2002 at 06:44:19PM +0100, Davi
at 07:19:25PM +0100, David Reid wrote:
> > OK, but let's assume that apr is needed for these. I mean they are based
on
> > apr (apr as in the original plain old boring apr library) right? Then I
> > guess what I don't understand is why we don't simply have the pack
I find myself agreeing with Aaron here. We need to revisit this and fix it
correctly...
(Damn - agreeing with Aaron again...)
david
- Original Message -
From: "Aaron Bannert" <[EMAIL PROTECTED]>
To:
Sent: Thursday, September 19, 2002 7:09 PM
Subject: Re: cvs commit: apr-util CHANGES apu
> > If you do change how the MMAP type works, I have a suggestion. MMAP's
are
> > void *'s with size's, and that is the only way to really make sense of
an
> > MMAP. Make the new structure something like:
> >
> > /* $(platform)_mmap_t are incomplete types implemented per OS */
> > typedef union {
I'm seeing build breakage on beos due to the windows header crud from expat
being included in exports.c... Not sure why as it all looks good but maybe
our awk export can have a quick look or email me direct to get a fix? Ta.
david
If we don't have such a declare maybe we should add one? I say this as
htpasswd.c (in httpd) uses P_tmpdir that isn't portable and breaks the beos
build. Also Thom found a note in his stdio.h file saying that it wasn't the
right way to do things, and I agree it's not.
I propose that it would simp
> > If we don't have such a declare maybe we should add one? I say this as
> > htpasswd.c (in httpd) uses P_tmpdir that isn't portable and breaks the
beos
> > build. Also Thom found a note in his stdio.h file saying that it wasn't
the
> > right way to do things, and I agree it's not.
> >
> > I pro
Actually I think we should have 3 new functions...
char *apr_temp_get_directory(apr_pool_t *)
char *apr_temp_get_filename(char *dir, char *suffix, apr_pool_t *)
char *apr_temp_get_unique(char *suffix, apr_pool_t *)
This gives us the ability to let the users do what they like and maximum
flexabili
avid
- Original Message -
From: "Wilfredo Sanchez" <[EMAIL PROTECTED]>
To: "Apache Portable Runtime Developers"
Sent: Saturday, December 07, 2002 7:36 AM
Subject: Re: APR_TMP_DIRECTORY
> On Wednesday, December 4, 2002, at 10:53 PM, David Reid wrote:
>
Damn, I could have sworn this was an apr list!
How did we get from something very simple to this??? Fred, if you really
want to implement this then feel free, but this is a long wqay from what is
needed IMHO and smacks of overengineering :( .
david
>So I'm clear, here's what I suggest. Two
> > > Fine, then suggest another method for developers to find a system temp
> > > directory so that they can create a valid mask for use in
> > > apr_file_mktemp.
> >
> > If they need more than a tmp file handle with a clear contract; i.e.
> > something like pseudo temporarly storage with semantic
Actually my memory is that we don't any form of agreement on how this should
be implemented or even what problem the discussion was trying to solve -
that's why I haven't written anything yet. I was all set to write the code
but the discussion and feeling expressed mean I won't now.
It'll be nice
I'd rather see it documented and the issues looked at on the other
platforms.
It was added as we originally had TCP_CORK and that is Linux only. We detect
whether we have TCP_NOPUSH and try to make the usage as general as
possible - that process should be fixed and improved on :)
david
- Ori
Yeah nice thought but it's been vetoed by quite a few folks. You do read the
same list I do don't you? :)
david
- Original Message -
From: "Branko Äibej" <[EMAIL PROTECTED]>
To: "David Reid" <[EMAIL PROTECTED]>; "APR Dev List"
Sent: T
> > --On Thursday, January 9, 2003 1:07 PM -0600 "William A. Rowe, Jr."
> > <[EMAIL PROTECTED]> wrote:
> >
> > > No, as I original proposed, httpd-2.2 will target APR 1.0. In
> > > fact, httpd-2.2 won't even be released until APR hits that magic
> > > number. All the old cruft deprecated over th
Phillipe, your patches missed the email. Maybe you'd like to rebook on a
later email?
david
- Original Message -
From: "Philippe M. Chiasson" <[EMAIL PROTECTED]>
To:
Sent: Thursday, January 30, 2003 3:10 PM
Subject: [PATCH] apr-util/buckets/apr_buckets_socket.c UDP friendly
> I noticed
1 - 100 of 398 matches
Mail list logo