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.
This one is an
Here's the code for the general-case poll API. I've run out
of time for today, so I'm posting this as a patch rather than
committing it, in hopes that someone else may be able to pick
it up tomorrow (I'll be in meetings much of the day).
This code compiles, but it hasn't been tested.
Known
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
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 lightweight, single-function poll API for
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
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.
Here are some resources which you might consider during the
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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
Ryan Bloom [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Ryan Bloom [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Brian Pane [EMAIL PROTECTED] writes:
To continue the recent discussions on the problems in the
current
apr_poll API, here's a patch for
Ryan Bloom [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Ryan Bloom [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Brian Pane [EMAIL PROTECTED] writes:
To continue the recent discussions on the problems in the
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 would
do,
so I
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
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 lightweight, single-function
Ryan Bloom [EMAIL PROTECTED] writes:
I suspect that rebuilding the native pollset (e.g., struct pollfd
array) every time apr_poll() is called is harmful to Apache.
It should actually perform better than the previous version of the code,
for small pollsets, which is what most people use
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Ryan Bloom [EMAIL PROTECTED] writes:
I suspect that rebuilding the native pollset (e.g., struct pollfd
array) every time apr_poll() is called is harmful to Apache.
It should actually perform better than the previous version of the
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.
What I'm proposing here is to split the API
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.
What I'm proposing here
Brian Pane [EMAIL PROTECTED] writes:
Jeff Trawick wrote:
...
The current implementation is useful if the user has to find out if
the socket is readable/writable WITHOUT CONSUMING THE DATA and it is
inconvenient to keep track of the APR representation of the
pollset. If they are going to turn
At 01:17 PM 7/29/2002, Brian Pane wrote:
hmmm...another characteristic of the use case in which the current
API is useful is that there's exactly one descriptor involved. Would
that yield a useful simplification of the two-API plan? I'm thinking
of something like:
- apr_pollset API for
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
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 parts:
- A lightweight,
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 parts:
- A
22 matches
Mail list logo
