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
17 matches
Mail list logo
