This patch should allow the APR testpoll test to work with pollset
implementations
where readability and writability events on the same descriptor can
end up in two
separate pollfd_t objects, such as kqueue.
The only pollset implementations for which I have test environments,
though, are
se
On Dec 30, 2005, at 6:48 PM, Roy T. Fielding wrote:
On Dec 30, 2005, at 5:51 PM, Brian Pane wrote:
I haven't been able to find the bug yet. As a next step, I'll try
using
valgrind on a build with pool debugging enabled.
On entry to allocator_free, if
(node == node->
For a while now, we've disabled the use of poll(2) in APR on
OS X 10.4 because of the problem described in
http://issues.apache.org/bugzilla/show_bug.cgi?id=34332 :
poll could report a socket as writable, but a write on the socket
would then fail with EAGAIN.
Noting that there's a new release of
On Nov 25, 2005, at 5:38 AM, Joe Orton wrote:
On Wed, Nov 23, 2005 at 05:38:58PM -, Brian Pane wrote:
Author: brianp
Date: Wed Nov 23 09:38:47 2005
New Revision: 348499
URL: http://svn.apache.org/viewcvs?rev=348499&view=rev
Log:
Bugfix for apr_pollset_poll() on systems that imple
On Nov 25, 2005, at 5:31 AM, Joe Orton wrote:
On Thu, Nov 24, 2005 at 11:21:22AM +0200, Graham Leggett wrote:
Hi all,
While trying to do a subversion operation from a MacOSX machine
within a
volume mounted from a WinXP share, I am getting the following error:
subversion/libsvn_subr/io.c:2
On Nov 21, 2005, at 2:21 PM, Gerry wrote:
Evening Gents,
Spotted a real oddity in apr_pollset_poll in both select.c and
poll.c in the
current version 1.2.2 and in the versions used in apache2 20.54 and
2.1.9.
Patch for select.c and test case committed to the APR trunk...I couldn't
reprodu
Thanks for diagnosing this. I'm adding a check for this bug into
the APR unit tests now. Once that's ready, I'll commit the fix for
select.c.
Brian
On Nov 21, 2005, at 2:21 PM, Gerry wrote:
Evening Gents,
Spotted a real oddity in apr_pollset_poll in both select.c and
poll.c in the
current
Tony Reix wrote:
Who knows on which architectures:
ia32 surely
x86_64 probably
PPC??
ia64 ??
...
APR has been compiled/tested ?
I don't know the full list, but APR has been compiled/tested/used
on ia32, ia64, x86_64, PPC, SPARC (32- and 64-bit
Thanks. Are you +1 for backporting to both apr-1.1 and apr-1.0? (I
put in a separate
vote in 1.0's STATUS file, since that has the same code for creating
the pollset.)
Can a couple of other cast votes on this?
Thanks,
Brian
On Jul 15, 2005, at 11:13 PM, William A. Rowe, Jr. wrote:
++1 -
Thanks. Are you +1 for backporting to both apr-1.1 and apr-1.0? (I
put in a separate
vote in 1.0's STATUS file, since that branch has the same code for
creating the pollset.)
Can a couple of other committers please cast votes on this, too?
Thanks,
Brian
On Jul 15, 2005, at 11:13 PM, Willi
On Jul 18, 2005, at 5:41 AM, Joe Orton wrote:
On Sun, Jul 17, 2005 at 07:20:10PM -0700, Brian Pane wrote:
For implementations of apr_pollset that support the
APR_POLLSET_THREADSAFE option to apr_pollset_create(), what's
supposed
to happen if thread T1 adds a descriptor to a pollset
For implementations of apr_pollset that support the
APR_POLLSET_THREADSAFE option to
apr_pollset_create(), what's supposed to happen if thread T1 adds a
descriptor to a pollset
while thread T2 is blocked in a call to apr_pollset_poll() for the
same pollset?
Because the comments in apr_poll.
On Jul 4, 2005, at 2:18 AM, Joe Orton wrote:
On Sun, Jul 03, 2005 at 04:27:05PM -0700, Brian Pane wrote:
I just did some performance profiling of httpd-2.1 for the first time
in a long while.
One of the odd things I noticed is that apr_file_open() appears to
spend half its time
in a call to
On Jul 4, 2005, at 2:18 AM, Joe Orton wrote:
On Sun, Jul 03, 2005 at 04:27:05PM -0700, Brian Pane wrote:
I just did some performance profiling of httpd-2.1 for the first time
in a long while.
One of the odd things I noticed is that apr_file_open() appears to
spend half its time
in a call to
I just did some performance profiling of httpd-2.1 for the first time
in a long while.
One of the odd things I noticed is that apr_file_open() appears to
spend half its time
in a call to apr_pollset_create().
The pollset creation can be expensive, especially on platforms where
it's implem
On Apr 21, 2004, at 9:11 AM, Sumeet Singh wrote:
Hi,
In my use-case I am dealing with multiple headers with the same key
(e.g. Cookie), and need to modify or remove a specific header based on
its key and value (e.g. remove a certain cookie header while leaving
the rest in). There is no api in
On Apr 21, 2004, at 9:11 AM, Sumeet Singh wrote:
Hi,
In my use-case I am dealing with multiple headers with the same key
(e.g. Cookie), and need to modify or remove a specific header based on
its key and value (e.g. remove a certain cookie header while leaving
the rest in). There is no api in
On Nov 16, 2003, at 12:05 PM, Jeff Trawick wrote:
this will resolve two types of problems:
1) all implementations will then be required to use a single set of
function prototypes, avoiding some problems we've had getting all
platform logic to agree on what the prototype should be
2) allow bug fi
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 apr_bucket_t;
typedef struct apr_bucket_brigade_t apr_bucket_
Thanks to all who provided feedback on the apr_atomic API
changes that I posted last week. Here's the updated patch
that I'm planning to commit; I'll wait a few days in case
more people want to comment.
Things that have changed since the original patch:
- Added a new function apr_atomic_xchg32 to
[EMAIL PROTECTED] wrote:
Brian Pane wrote:
On Sat, 2003-09-13 at 07:29, Wan-Teh Chang wrote:
1. It seems that you intentionally do not want the add32, sub32,
and inc32 return a value. Only the dec32 function returns a
value, and that value can only be used as a boolean (zero or
nonzero).
2
On Sun, 2003-09-14 at 06:20, David Reid wrote:
> As we're approaching the time when we do a 1.0 why not simply remove the old
> interface rather than simply deprecate them? We shouldn't carry more into
> 1.0 then we need to after all!
+1 from me
Brian
On Sat, 2003-09-13 at 07:29, Wan-Teh Chang wrote:
> 1. It seems that you intentionally do not want the add32, sub32,
> and inc32 return a value. Only the dec32 function returns a
> value, and that value can only be used as a boolean (zero or
> nonzero).
> 2. There is no atomic exchange function t
The current apr_atomic API has a couple of limitations:
* The size of apr_atomic_t varies among platforms, which
makes it hard to guarantee portability of applications
that use this type to store large values.
* The arithmetic functions use apr_atomic_t, while the
compare-and-swap function
On Thu, 2003-07-03 at 07:31, [EMAIL PROTECTED] wrote:
> Brian Pane wrote:
>
> >> What are the real issues stopping us from releasing APR 1.0?
>
> > We still have the 64-bit divisions in the apr_time_t code.
>
> It sure would be nice to make this one go away
On Sun, 2003-08-31 at 09:56, Justin Erenkrantz wrote:
> I'd like to propose a vote:
>
> [ ] - 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 __
Depending on just how hastily you want to tag a release,
I'd like to clean u
On Tue, 2003-08-12 at 20:20, Cliff Woolley wrote:
> 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 ch
The pool design currently can't support this. It's optimized
for allocation speed; in the common case, apr_palloc requires
only a pointer addition. The downside of this design is that
there's no way to reclaim memory within a pool.
There's been talk in the past of trying a more general-purpose
al
Cliff Woolley wrote:
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...
We still have the 64-bit divisions in the apr_time_t code.
Brian
Saxon Druce wrote:
- Original Message -
From: "Brian Pane" <[EMAIL PROTECTED]>
To: "APR dev"
Sent: Wednesday, June 25, 2003 2:42 PM
Subject: Re: [PATCH] filepath.c with Borland C++ Builder
why initialize separator only
to overwrite it? I.e., why not:
char s
Saxon Druce wrote:
--- apr/file_io/win32/filepath.c.oldTue May 13 14:35:32 2003
+++ apr/file_io/win32/filepath.cTue May 13 14:38:31 2003
@@ -156,9 +156,11 @@
#else /* ndef(NETWARE) */
-char seperator[2] = { (flags & APR_FILEPATH_NATIVE) ? '\\' : '/', 0};
+char seperator[2] = {0,
On Mon, 2003-06-23 at 05:02, Jeff Trawick wrote:
> [EMAIL PROTECTED] wrote:
> > brianp 2003/06/22 14:50:25
> >
> > Modified:include apr_tables.h
> >tables apr_tables.c
> > Log:
> > Add an apr_table_compress() function to reconcile duplicate
> > entries in a tabl
I'll take a look at this today.
On Mon, 2003-06-23 at 05:02, Jeff Trawick wrote:
> [EMAIL PROTECTED] wrote:
> > brianp 2003/06/22 14:50:25
> >
> > Modified:include apr_tables.h
> >tables apr_tables.c
> > Log:
> > Add an apr_table_compress() function to reconcile
which flag value is set.
Brian
On Sun, 2003-06-22 at 13:23, Brian Pane wrote:
> On Wed, 2003-06-18 at 08:10, Joe Schaefer wrote:
>
> > I added back the callbacks apreq needs,
> > and moved the table_reindex call inside
> > the dups_found test. Here's the correspond
On Wed, 2003-06-18 at 08:10, Joe Schaefer wrote:
> I added back the callbacks apreq needs,
> and moved the table_reindex call inside
> the dups_found test. Here's the corresponding
> oprofile data:
Thanks. I'll merge in the version of mergesort that
has a return value, run some final tests, and
On Sun, 2003-06-01 at 19:41, Joe Schaefer wrote:
> Brian Pane <[EMAIL PROTECTED]> writes:
>
> > Here's a modification of Joe Schaefer's table patch that uses
> > a mergesort to do apr_table_compress and apr_table_overlap.
> >
> > This will ensure a
Here's a modification of Joe Schaefer's table patch that uses
a mergesort to do apr_table_compress and apr_table_overlap.
This will ensure a worst-case run time of n*log(n) instead
of n^2. However, I'm not sure whether the extra complexity
of the mergesort will hurt the performance on small data
#x27;m +1 for
making this change in APR. Can a few other committers weigh in?
Thanks,
Brian
On Tue, 2003-05-20 at 17:25, Joe Schaefer wrote:
> Brian Pane <[EMAIL PROTECTED]> writes:
>
> > Thanks, it works much better with that change.
> > One more question: do you have a way
fig will allow up to a 100-line header, which is a large
enough 'n' to make me paranoid about O(n^2) DoS vulnerabilities.
Thanks,
Brian
Joe Schaefer wrote:
Brian Pane <[EMAIL PROTECTED]> writes:
I just applied the patch (both the APR and httpd parts) and ran
the httpd-test re
I just applied the patch (both the APR and httpd parts) and ran
the httpd-test regression tests. Something is broken:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
apache/acceptpathinfo.t
On Sat, 2003-05-17 at 21:53, Joe Schaefer wrote:
> Joe Schaefer <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > oprofile tells me this version wins by ~10 - 25% when measuring the
> > time httpd spends in table ops. To get the full benefit,
> > ap_get_mime_headers_core in httpd-2.0/server/protocol.
I've been meaning to review this patch for the past week,
but I haven't had time to give it the attention it deserves.
For now, some general thoughts on the design...
On Sat, 2003-05-10 at 15:22, Joe Schaefer wrote:
> Joe Schaefer <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > Has anyone given any
On Sat, 2003-03-22 at 20:39, Craig Rodrigues wrote:
> -#define apr_atomic_set(mem, val) atomic_set_int(mem, val)
> +#define apr_atomic_set(mem, val) (*(mem) = val)
This part looks okay; we make the same assumption (that
a 32-bit aligned write is atomic) on many other platforms.
> #defin
On Mon, 2003-01-13 at 12:21, Greg Ames wrote:
> Brian Pane wrote:
> > I'm planning on spinning around the CAS; i.e., retry if the
> > CAS fails due to a collision with another thread. The queue_info
> > synchronization, which uses that same technique, seems to be
&g
Greg Ames wrote:
> Brian Pane wrote:
> > Greg Ames wrote:
>
>
> >> apr_atomic_dec? That does return something.
>
> > The problem is that, since we have to use apr_atomic_cas for the
> > increment (due to the lack of a return value on apr_atomic_inc),
>
William A. Rowe, Jr. wrote:
In that case... what about a trick (I believe) Ben Laurie taught us?
Using a typedef for clarity:
typedef void*(*apr_atomic_casptr_fn_t)(unsigned long* mem, unsigned long cmp,
unsigned long with);
#define apr_atomic_casptr ((apr_atomic_casptr_fn_t)(atomic_cmpxchg))
In t
Greg Ames wrote:
+/* Atomically decrement the idle worker count */
+for (;;) {
+apr_uint32_t prev_idlers = queue_info->idlers;
+if (apr_atomic_cas(&(queue_info->idlers), prev_idlers - 1,
prev_idlers)
+== prev_idlers) {
+break;
+
On Wed, 2003-01-08 at 07:15, William A. Rowe, Jr. wrote:
> Just an observation reviewing the apr/includes/ changes... I don't like the
> look of this code;
>
> +#define apr_atomic_casptr(mem,with,cmp) (void*)atomic_cmpxchg((unsigned long
> *)(mem),(unsigned long)(cmp),(unsigned long)(with))
>
>
On Fri, 2003-01-03 at 08:05, Joe Orton wrote:
> On Tue, Dec 31, 2002 at 05:10:40PM -, William Rowe wrote:
> > Modified:poll/unix poll.c
> > Log:
> > Fix apr_poll behavior on Darwin/Win32 (now passing testpoll.)
> > We were getting spurious returned events because the select-base
While trying to replace some mutex-based synchronization
code in the httpd with atomic spinloops, I ran into a
problem in the APR atomic API:
With the API split between apr_uint32_t for the CAS
operation and apr_atomic for most of the get/set
operations, it's impossible to use write portable apps
On Sun, 2002-12-29 at 19:10, Erik Abele wrote:
> seems that this has something to do with the latest changes in
> apr/file_io/unix/open.c... the following patch works fine for me.
>
> --- /home/cvs/apr/file_io/unix/open.c Mon Dec 30 02:58:01 2002
> +++ open.cMon Dec 30 03:59:26 2002
> @@ -14
On Sat, 2002-12-21 at 09:52, [EMAIL PROTECTED] wrote:
> No, that is a solution, in fact, it was part of the original design.
And we've discussed already, it's a flaw in the original design,
because it requires that the app either maintain a long-lived
connection-level pool (with unbounded memory
On Sat, 2002-12-21 at 07:58, [EMAIL PROTECTED] wrote:
> I'm really sorry, but I am sick of hearing this isn't a solution for apps
> in general. This is now the fourth time that I have asked for a clear
> description of _why_. I helped to design and write buckets and
> bucket_brigades. I underst
On Fri, 2002-12-20 at 22:03, Cliff Woolley wrote:
> Can we at least agree to do one thing:
> release 2.0.44 *without* Brian's change.
Okay with me.
> Then we can sort out the best
> course of action without delaying the entire release process on the stable
> branch. It might well be that the
On Fri, 2002-12-20 at 21:37, [EMAIL PROTECTED] wrote:
> On 20 Dec 2002, Brian Pane wrote:
>
> > On Fri, 2002-12-20 at 13:50, [EMAIL PROTECTED] wrote:
> >
> > > > Basically, if you received a brigade from a higher filter, you can only
> > > > assume t
On Fri, 2002-12-20 at 13:50, [EMAIL PROTECTED] wrote:
> > Basically, if you received a brigade from a higher filter, you can only
> > assume that it will survive a single trip down the filter stack.
Right. And you also can't assume that the context that passed
the brigade down the filter stack s
On Fri, 2002-12-20 at 12:19, [EMAIL PROTECTED] wrote:
> As for this not working when the filter and handler are in different
> threads, of course it will. As long as the buckets are copied into a
> brigade that was allocated out of a pool that will still be alive when the
> filter is called, this
On Fri, 2002-12-20 at 11:24, [EMAIL PROTECTED] wrote:
> U, I don't believe that it is possible for a brigade to outlive the
> transaction that created it, especially not when you look at how brigades
> are used in the web server.
Sure it can. An output brigade created in a subrequest, for
ex
On Fri, 2002-12-20 at 07:32, Bill Stoddard wrote:
> If a pool is passed to apr_brigade_create, the brigade is allocated out of the
> pool. If the pool is NULL, the brigade is allocated out of the bucket
> allocator.
> We don't want a pool pointer hanging around in a brigade allocated out of the
>
On Fri, 2002-12-20 at 08:57, [EMAIL PROTECTED] wrote:
> I am actually pretty sure that allocating brigades out of the
> bucket_allocator is a VERY big mistake. In fact, I am close to asking
> that change to be backed out because it is too dangerous.
>
> When we first designed buckets and bucket b
On Sat, 2002-11-16 at 17:39, Aaron Bannert wrote:
> Looks like a bug to me. Any reason we need nested locks on cross-process
> mutexes? I'm tempted to just rip out that part and see what breaks.
Intraprocess mutexes have the same problem. Because mutex->owner
is of type apr_os_thread_t, there's n
On Sun, 2002-09-29 at 17:19, Greg Stein wrote:
> On Sun, Sep 29, 2002 at 01:05:38AM -, [EMAIL PROTECTED] wrote:
> > brianp 2002/09/28 18:05:38
> >
> > Modified:buckets apr_brigade.c
> > Log:
> > Rewrite of apr_brigade_writev(). It's now more efficient for
> > both large and
On Mon, 2002-09-23 at 03:30, Greg Stein wrote:
> On Sun, Sep 22, 2002 at 07:00:42PM -0700, Brian Pane wrote:
> > On Sun, 2002-09-22 at 16:34, Greg Stein wrote:
> >...
> > All the copying doesn't bother me as much, because it's the same
> > thing that wou
On Sun, 2002-09-22 at 16:34, Greg Stein wrote:
> Ewww... icky implementation... If you have a dozen iovec's where each
> iov_len is slightly less than APR_BUCKET_BUFF_SIZE, then you're going to
> copy the entire thing onto the heap.
>
> > +/* Step 3: if necessary, output the brigade content
Thanks, I just committed the patch.
-Brian
On Sun, 2002-09-22 at 10:18, Kean Johnston wrote:
> Hi,
>
> Please consider the follow patch I needed to make to get APR working
> on SCO OpenServer Release 5. Briefly, here is what I needed to change:
>
> a) Since you're using config.guess and config.s
On Wed, 2002-09-18 at 04:00, jean-frederic clere wrote:
> Hi,
>
> We would like to use the pcre of httpd-2.0/srclib/pcre in mod_jk2
> (Jakarta-Tomcat).
>
> I think there are no reason to have pcre in httpd-2.0 so I would like to move
> pcre to apr-util.
>
> Any comments?
I don't have any obje
Jeff Trawick wrote:
What will happen if keys and values in b are NOT from an ancestor of
a's pool but b has sufficient lifetime?
I'm debugging a segfault in hash_overlap() when driven by a 3rd party
Apache module. Clearly the 3rd party module is misusing
apr_table_overlap() because a is from the r
Cliff Woolley wrote:
On Sat, 31 Aug 2002, Brian Pane wrote:
Wouldn't it be sufficient to guarantee that:
* each *bucket* can only be processed by one thread at a time, and
* allocating/freeing buckets is thread-safe?
No. You'd need to also guarantee that all of the buckets
Cliff Woolley wrote:
On Sat, 31 Aug 2002, Brian Pane wrote:
I don't think we can count on the assumption that each conn will
only be processed by one thread at a time. For example, this race
Then we have to at least guarantee that each request can only be processed
by one thread at a
Cliff Woolley wrote:
On Sat, 31 Aug 2002, Brian Pane wrote:
* The bucket allocator alloc/free code isn't
thread-safe, so bad things will happen if the
writer thread tries to free a bucket (that's
just been written to the client) at the same
time that a worker thread is al
I've been thinking about strategies for building a
multiple-connection-per-thread MPM for 2.0. It's
conceptually easy to do this:
* Start with worker.
* Keep the model of one worker thread per request,
so that blocking or CPU-intensive modules don't
need to be rewritten as state machines.
Ian Holsman wrote:
Is there any interest in adding a generalized version of worker's
fdqueue to apr-util (this is a FIFO not a stack btw) ???
+1
Brian
William A. Rowe, Jr. wrote:
At 06:15 PM 8/13/2002, [EMAIL PROTECTED] wrote:
The time formatting features are for apr_time_t, and should require
microseconds. If you want to use time formatting functions for seconds,
then you have to use the ANSI standard functions. Essentially, using a
time_t in
Roy T. Fielding wrote:
Oh, for crying out loud. Apps do not need microsecond resolution for
time since epoch. None of them do.
I agree strongly with Roy's main argument, although I
have objections to this particular part.
I can think of examples where apps need the time since
the epoch in subsec
Greg Stein wrote:
I just wanted to hilite this change, in case people missed it. Our output
library now looks like: libapr-0.so
(and when we release 1.x.y it will be libapr-1.so)
If you've got problems or concerns or whatever with the change, then now is
the time :-)
[ note: I also plan to shift th
[EMAIL PROTECTED] wrote:
yOn Tue, 13 Aug 2002, Brian Pane wrote:
[EMAIL PROTECTED] wrote:
To use time_t in a portable app, though, I expect that we'll still
need to rely on APR to provide a portability wrapper. The code for
even simple things like getting the current time is diff
[EMAIL PROTECTED] wrote:
To use time_t in a portable app, though, I expect that we'll still
need to rely on APR to provide a portability wrapper. The code for
even simple things like getting the current time is different between
Unix and Win32. (I wouldn't mind leaving apr_time_t as-is if we
als
[EMAIL PROTECTED] wrote:
On Tue, 13 Aug 2002, Brian Pane wrote:
[EMAIL PROTECTED] wrote:
I continue to state that APR's time format should stay as it is. If you
want seconds, use time_t. The only change that I can see as appropriate,
is to make the interval_time_t a 32-bit value,
Justin Erenkrantz wrote:
On Tue, Aug 13, 2002 at 03:10:14PM -0400, Jim Jagielski wrote:
Uh oh. Looks like we'll be hashing this out again :)
Which is exactly why we should table the time discussion until
we have a versioning system *enforced*.
I must object. The performance problems in the
Ryan Bloom wrote:
That is in Apache, which has nothing to do with APR. The proposal
specifically states that APR will stop dealing with microseconds, which
makes it useless for an app outside of httpd that wants microsecond
resolution.
On the contrary, removing the microsecond manipulation from AP
[EMAIL PROTECTED] wrote:
Toward the end of that last round of discussions, I thus proposed
that APR get out of the business of managing microseconds:
http://marc.theaimsgroup.com/?l=apr-dev&m=102678180413988
I'm interested in hearing people's comments on that proposal.
Doesn't that completely
Ryan Bloom wrote:
On Tue, 13 Aug 2002, Aaron Bannert wrote:
On Tue, Aug 13, 2002 at 11:15:48AM -0700, Brian Pane wrote:
I think APR is close to being ready for 1.0. We still need to
fix the apr_time_t performance problems (the old 64-bit division
issue), though.
Can we plan on
Jim Jagielski wrote:
Aaron Bannert wrote:
I move that we implement a runtime version checking scheme in APR and
then release 1.0 as soon as possible, at the same time adopting the
above versioning definitions.
Assuming that we all sign up to the statement that APR is 1.0 ready, or
soon will
Roy T. Fielding wrote:
The warning is simply because gcc can't follow conditionals, but
this should be a safe fix if nobody minds.
I think an even safer fix would be to turn that last
"else if" into an "else." If we just initialize the
value to zero, we might end up polling fd 0 if a
caller pass
Thanks for the fix. I just committed it.
Brian
Rob Saccoccio wrote:
The descriptors return value for apr_pollset_poll() isn't setup in the
!HAVE_POLL path..
--rob
diff -u -r1.26 poll.c
--- poll.c 4 Aug 2002 04:43:23 - 1.26
+++ poll.c 6 Aug 2002 01:18:17 -
@@ -602,6 +624,7 @
Rob Saccoccio wrote:
I like the concept, but...
+else if (aprset[i].desc_type == APR_NO_DESC) {
+pollset[i].fd = -1;
+continue;
I'm not sure if it's safe to have an fd of -1 in the pollset.
I don't know if its portable but its the right approach on S
Rob Saccoccio wrote:
The pollset API seems to be missing something...
create a pollset with size 100
add 50 descriptors
call poll()
If poll returns with 20 descriptors ready, I can't traverse the 20 ready
descriptors because they're scattered over an array of 50.
No, they're the first 20 in the
Rob Saccoccio wrote:
The following patch to HEAD corrects problems with the transparent poll API.
Currently, the apr_poll_t struct is handled ambiguously WRT whether its
entries are packed or sparse. The brokeness has probably not been apparent
because in httpd entries are never removed.
I like th
William A. Rowe, Jr. wrote:
At 10:15 AM 8/3/2002, Rob Saccoccio wrote:
Its not clear to me which poll API should be used when. Apache uses the
deprecated API. Some thoughts on the subject should probably be put in
poll.h and Apache updated.
I'm as stumped as you. FWIW, both should work. It m
g-term solution
is probably to build a balanced tree out of the entries for
O(log(n)) insertion, deletion, and lookup; but I think the
current solution is probably good enough for the first release.
(The original poll API was O(n) for all of these.)
Brian
Jeff Trawick wrote:
Brian Pane <
Jeff Trawick wrote:
Brian Pane <[EMAIL PROTECTED]> writes:
To continue the recent discussions on the problems in the current
apr_poll API, here's a patch for apr_poll.h that illustrates my
proposed fix.
...
- A general-purpose poll API for larger sets of descriptors.
Thi
Bill Stoddard wrote:
Hummm. I was thinking we would create an entirely new set of APR calls
to encapsulate an event drivent network i/o interface (/dev/poll,
KQEnqueue/KQDequeue, IOCompletion ports, etc.). I'll try to work up an API
this week.
Sounds good. In the meantime, we still need to rev
William A. Rowe, Jr. wrote:
- lightweight API that just checks a single descriptor for readability
or writability
We have that [this is what started the argument.] But I'd argue that up
to five or six sources are very useful, consider two ideas;
1. apr_poll learns to support brigades, so that
Jeff Trawick wrote:
Brian Pane <[EMAIL PROTECTED]> writes:
Jeff Trawick wrote:
Brian Pane <[EMAIL PROTECTED]> writes:
To continue the recent discussions on the problems in the current
apr_poll API, here's a patch for apr_poll.h that illustrates my
proposed fix.
W
Jeff Trawick wrote:
Brian Pane <[EMAIL PROTECTED]> writes:
To continue the recent discussions on the problems in the current
apr_poll API, here's a patch for apr_poll.h that illustrates my
proposed fix.
What I'm proposing here is to split the API into two parts:
- A lig
Ryan Bloom wrote:
I am biting my tongue here, but Jeff, you are the person who
specifically stated that the heavy-duty API was too slow for us
to
use.
I said it was too slow and/or cumbersome to use in a particular
situation that does not correspond to something an APR app woul
Justin Erenkrantz wrote:
On Fri, Jul 26, 2002 at 07:50:55PM -0700, Brian Pane wrote:
To continue the recent discussions on the problems in the current
apr_poll API, here's a patch for apr_poll.h that illustrates my
proposed fix.
What I'm proposing here is to split the API into two
To continue the recent discussions on the problems in the current
apr_poll API, here's a patch for apr_poll.h that illustrates my
proposed fix.
What I'm proposing here is to split the API into two parts:
- A lightweight, single-function poll API for use (only!)
with very small sets of descripto
Sander Striker wrote:
I'd like to keep the current code and see the mem leak fixed. That should
for the moment suffice. For large pollsets a workable solution was provided,
making the veto against the current code even harder to grok.
Which solution was the workable one for large pollsets? If yo
Ryan Bloom wrote:
The current API has a memory leak that makes it unsuitable for
general-purpose use (including the httpd). That's why I vetoed it.
Thatis just BS. This conversation started today with a solution to the
memory leak.
The conversation started with the showstopper in the httpd S
1 - 100 of 367 matches
Mail list logo
