You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Brian Pane <br...@apache.org> on 2002/07/27 04:50:55 UTC
[Request for comments] new poll API
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 descriptors. This is basically
the current implementation, but with a limit on the number
of descriptors that it will accept. With this limit, we
can put the temporary pollfd array on the stack in apr_poll()
to eliminate the memory leak.
- A general-purpose poll API for larger sets of descriptors.
This one is an abstract data type, accessible only through
functions, so that we can do internal optimizations in the
future (like replacing poll with /dev/poll on supported
platforms).
Comments welcome...
Thanks,
Brian
Re: [Request for comments] new poll API
Posted by Brian Pane <br...@apache.org>.
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 lightweight, single-function poll API for use (only!)
>> with very small sets of descriptors. This is basically
>> the current implementation, but with a limit on the number
>> of descriptors that it will accept. With this limit, we
>> can put the temporary pollfd array on the stack in apr_poll()
>> to eliminate the memory leak.
>>
>>
>
>My one concern is whether we can degrade gracefully if someone
>calls with a too-high value to apr_poll(). Would it return an
>error, or have the overhead of using the abstract API and then
>calling the other variant for you?
>
It would return an error in this case. My rationale is that creating
and destroying a temporary instance of the abstract pollset object
is likely to be expensive--multiple syscalls, for example, if it's
implemented using /dev/poll. The abstract pollset is really best
suited for applications that re-use the same pollset (potentially
with descriptors added and removed incrementally) many times to
amortize the cost of the creation/deletion over many poll calls.
If the app wants to call the "quick and dirty" form of the poll API
with two hundred socket descriptors, IMHO that's a problem with the
application design. And rather than trying to make it work, we
should just let the application developer fix their code to use a
persistent pollset object and the abstract API.
>The reason is that if the limit of apr_poll() is tunable at
>compile-time, then what may work for one installation may not
>work for another. That worries me. I definitely don't want
>to have to check for apr_poll() returning an error and then
>having to code up for apr_pollset... -- justin
>
>
I think we can solve that one, though, by just declaring that
the limit can never be changed. E.g., we can't decrease the limit
(though we could potentially increase it) in future releases of
APR, and applications can't re-#define it.
Brian
Re: [Request for comments] new poll API
Posted by Justin Erenkrantz <je...@apache.org>.
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, single-function poll API for use (only!)
> with very small sets of descriptors. This is basically
> the current implementation, but with a limit on the number
> of descriptors that it will accept. With this limit, we
> can put the temporary pollfd array on the stack in apr_poll()
> to eliminate the memory leak.
My one concern is whether we can degrade gracefully if someone
calls with a too-high value to apr_poll(). Would it return an
error, or have the overhead of using the abstract API and then
calling the other variant for you?
The reason is that if the limit of apr_poll() is tunable at
compile-time, then what may work for one installation may not
work for another. That worries me. I definitely don't want
to have to check for apr_poll() returning an error and then
having to code up for apr_pollset... -- justin
Re: [Request for comments] new poll API
Posted by Jeff Trawick <tr...@attglobal.net>.
Brian Pane <br...@apache.org> 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 right around and consume the data
> >then they might as well play with socket options and call apr_recv().
> >If it is convenient to keep track of the APR representation of a
> >pollset, then it doesn't matter either way.
> >
> >I'm not sure that I see the compelling use-case but for various
> >reasons it is probably best for me to assume that there are plenty of
> >them. Hopefully having a separate API won't be confusing to APR
> >programmers.
> >
> >ugh :)
> >
> >
>
> hmmm...another characteristic of the use case in which the current
> API is useful is that there's exactly one descriptor involved.
strangely, I started to comment that I thought it should be a much
more *severely* limited number of descriptors... an application with
11 descriptors to check on today may very well have 21 descriptors to
check on tomorrow and the programmer may be frazzled at having to
switch APIs (or worse yet, recompile APR with a bigger limit and thus
frazzle our users :) )
meanwhile, an application just checking on one descriptor is more
likely to still be able to use the simple API tomorrow...
> that yield a useful simplification of the two-API plan? I'm thinking
> of something like:
>
> - apr_pollset API for general-purpose use (abstract interface,
> does its own memory management, etc)
>
> - lightweight API that just checks a single descriptor for readability
> or writability
That feels like a good thing to do.
> Of course, if we can only come up with a single use case for the second
> API, and it happens to be apr_wait_for_io_or_timeout(), then let's just
> inline the poll/select call there and forget about the lightweight API
> until we find another use case.
I usually would want to wait until there are more compelling scenarios
to justify putting in an API. A slight difference in this situation
is that we already have the API that I try to justify and what needs
to be added is the other one :)
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: [Request for comments] new poll API
Posted by Brian Pane <br...@apache.org>.
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 a filter stack might be
> plugged in later for cgi output. This probably is a combination of
> the
> APR_SPECULATIVE interface [is there anything on the stack] and
> a bit of intimate knowledge of the raw socket if there is nothing
> useful
> that's already sufficiently complete that is pending on the filter
> stack.
>
> 2. cgi needs to poll the cgi's stdout / stderr and the client input
> stack,
> while polling the cgi's stdin and client response stack for
> ready-to-write.
>
> This is a pretty tightly knit group of fd's that should be optimized
> for the
> small-set case.
In both of these cases, though, I think the abstract API
would work just fine--and it might well be a better choice
than transparent API. In both examples, the group of descriptors
would be long-lived (within the context of the request, at
least). E.g., in the CGI case, we'd be doing a poll on the
same stdout/stderr repeatedly until we got the input. And
the CGI handler is maintaining state between all those poll
calls, so it could easily use an instance of the general-purpose
abstract pollset object. And if we use that pollset multiple
times in a typical CGI request, it's more efficient to use the
encapsulated API than the transparent one, because the
encapsulated one can amortize the O(n) cost of setting up the
internall pollfd array over multiple poll invocations.
The cases where we'd really need a multi-descriptor transparent
API are those where the application can't easily keep track of
a pollset object between calls. I haven't been able to think of
a good example yet, though.
>> Of course, if we can only come up with a single use case for the second
>> API, and it happens to be apr_wait_for_io_or_timeout(), then let's just
>> inline the poll/select call there and forget about the lightweight API
>> until we find another use case.
>
>
> Well, I've offered the bigger-than-one case, which will be true for many
> apps that poll on stdin/stdout and some other socket or file entity.
> I really
> can't conceive of more than about 6 fd's in any obvious small-set case.
>
> But I agree, go with an abstract implementation, and make our existing
> apr_wait_for_io_or_timeout into the first special case. It's so
> darned simple
> that we shouldn't be trying to overwhelm it with multi-fd logic.
+1
Brian
Re: [Request for comments] new poll API
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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 general-purpose use (abstract interface,
> does its own memory management, etc)
This is extremely effective for any poll-based server daemon. We need
this so that the pollset can be manipulated for a group of listeners, and
it will become doubly necessary that it's very abstract if we will ever
support the async dispatch model in a poll-like fashion.
> - 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 a filter stack might be
plugged in later for cgi output. This probably is a combination of the
APR_SPECULATIVE interface [is there anything on the stack] and
a bit of intimate knowledge of the raw socket if there is nothing useful
that's already sufficiently complete that is pending on the filter stack.
2. cgi needs to poll the cgi's stdout / stderr and the client input stack,
while polling the cgi's stdin and client response stack for ready-to-write.
This is a pretty tightly knit group of fd's that should be optimized for the
small-set case.
>Of course, if we can only come up with a single use case for the second
>API, and it happens to be apr_wait_for_io_or_timeout(), then let's just
>inline the poll/select call there and forget about the lightweight API
>until we find another use case.
Well, I've offered the bigger-than-one case, which will be true for many
apps that poll on stdin/stdout and some other socket or file entity. I really
can't conceive of more than about 6 fd's in any obvious small-set case.
But I agree, go with an abstract implementation, and make our existing
apr_wait_for_io_or_timeout into the first special case. It's so darned simple
that we shouldn't be trying to overwhelm it with multi-fd logic.
I *really* empathize with Ryan that we should eat our own dogfood. But
our dogfood is built for an application like the server's accept pollset, or
the several handles of a good cgi implementation. We shouldn't convince
ourselves that the right solution for a one-of-many is the same solution
for a one-of-few, or a one-of-one. And we shouldn't clobber the good of
the many for the good of the few, or the one :-)
Bill
Re: [Request for comments] new poll API
Posted by Brian Pane <br...@apache.org>.
Jeff Trawick wrote:
>Brian Pane <br...@apache.org> writes:
>
>
>
>>Jeff Trawick wrote:
>>
>>
>>
>>>Brian Pane <br...@apache.org> 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 use (only!)
>>>> with very small sets of descriptors.
>>>>
>>>>
>>>>
>>>Do we really need this API? What is the sort of APR application for
>>>which the heavy-duty API is harmful?
>>>
>>>
>>>
>> But the
>>main limitation of the general-purpose API is that, because it involves
>>some memory allocation, you can't use it for spontaneous, one-time poll
>>calls (like checking for readability on a single input socket if read
>>just returned EAGAIN) unless you can guarantee that the number of such
>>calls during the lifetime of the request pool has an upper limit.
>>
>>
>
>This is the sort of thing I thought we'd start discussing a couple of
>hours ago :)
>
>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 right around and consume the data
>then they might as well play with socket options and call apr_recv().
>If it is convenient to keep track of the APR representation of a
>pollset, then it doesn't matter either way.
>
>I'm not sure that I see the compelling use-case but for various
>reasons it is probably best for me to assume that there are plenty of
>them. Hopefully having a separate API won't be confusing to APR
>programmers.
>
>ugh :)
>
>
>
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 general-purpose use (abstract interface,
does its own memory management, etc)
- lightweight API that just checks a single descriptor for readability
or writability
Of course, if we can only come up with a single use case for the second
API, and it happens to be apr_wait_for_io_or_timeout(), then let's just
inline the poll/select call there and forget about the lightweight API
until we find another use case.
--Brian
Re: [Request for comments] new poll API
Posted by Jeff Trawick <tr...@attglobal.net>.
Brian Pane <br...@apache.org> writes:
> Jeff Trawick wrote:
>
> >Brian Pane <br...@apache.org> 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 use (only!)
> >> with very small sets of descriptors.
> >>
> >
> >Do we really need this API? What is the sort of APR application for
> >which the heavy-duty API is harmful?
> >
>
> But the
> main limitation of the general-purpose API is that, because it involves
> some memory allocation, you can't use it for spontaneous, one-time poll
> calls (like checking for readability on a single input socket if read
> just returned EAGAIN) unless you can guarantee that the number of such
> calls during the lifetime of the request pool has an upper limit.
This is the sort of thing I thought we'd start discussing a couple of
hours ago :)
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 right around and consume the data
then they might as well play with socket options and call apr_recv().
If it is convenient to keep track of the APR representation of a
pollset, then it doesn't matter either way.
I'm not sure that I see the compelling use-case but for various
reasons it is probably best for me to assume that there are plenty of
them. Hopefully having a separate API won't be confusing to APR
programmers.
ugh :)
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: [Request for comments] new poll API
Posted by Brian Pane <br...@apache.org>.
Jeff Trawick wrote:
>Brian Pane <br...@apache.org> 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 use (only!)
>> with very small sets of descriptors.
>>
>>
>
>Do we really need this API? What is the sort of APR application for
>which the heavy-duty API is harmful?
>
This API really just adds programming convenience. There's nothing
it provides that can't be done with the general-purpose API. But the
main limitation of the general-purpose API is that, because it involves
some memory allocation, you can't use it for spontaneous, one-time poll
calls (like checking for readability on a single input socket if read
just returned EAGAIN) unless you can guarantee that the number of such
calls during the lifetime of the request pool has an upper limit. With
the general-purpose poll API, the solution is to hold onto your poll
object and re-use it if you have to poll the same descriptor(s) again.
The lightweight API just provides a simpler alternative for cases where
keeping track of the pollset object(s) would be prohibitively complex.
--Brian
Re: [Request for comments] new poll API
Posted by Brian Pane <br...@apache.org>.
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 would
>>>>
>>>>
>do,
>
>
>>>>so I don't consider that a valid use-case for justifying the
>>>>
>>>>
>simpler
>
>
>>>>API. (An APR app should be using an APR timeout socket option for
>>>>that situation.)
>>>>
>>>>
>>>Let me see if I understand. Apr_poll() is too slow for APR to use,
>>>
>>>
>but
>
>
>>>because you don't expect APR apps to use it too often, that is okay.
>>>Sorry, that doesn't hold water.
>>>
>>>
>>You are grasping for generalizations and taking a lot of liberties
>>with the facts along the way.
>>
>>
>
>Sorry, but I don't think so. The facts are simple. You said that
>apr_poll was both too slow and too complex for use inside of APR.
>
Jeff said it was too slow and complex for a specific use case
inside APR. You generalized that to "apr_poll is too slow for
APR to use," but the generalization isn't valid. There are
many cases inside APR where the implementation uses an inline
variant of some other APR API for performance reasons (the
array and string APIs are two examples that come to mind
immediately). Such cases don't mean that the API being bypassed
is unsuitable for use as a public API. They simply mean that
the code that's bypassing them has used an appropriate
optimization to deliver high performance to its own callers.
--Brian
RE: [Request for comments] new poll API
Posted by Ryan Bloom <rb...@covalent.net>.
> From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
>
> "Ryan Bloom" <rb...@covalent.net> 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 with Apache.
>
> I started off agreeing that the new implementation is faster for small
> pollsets, but I'm not sure that is the case when you consider
> steady-state operations. We save the overhead of the function call to
> look up the returned events after the poll call but we pick up the
> overhead of the internal call to get_event() just before poll() is
> called.*
That get_event() call can easily be removed in 99% of the cases (see
below).
> If APR had a small-pollset API and a big-pollset API, I suspect we'd
> be better off in Apache just using the big-pollset API rather than
> deciding at run-time which API to pick since implementing a choice
> would likely introduce an extra function call which would erase any
> small benefit of being able to use the small-pollset API.
In how many situations would we actually need to use the big-pollset
API? I would much rather just write the code to use the small-pollset
API, and possible #ifdef the big-pollset API. It would be faster to use
the small-pollset API, and if you _must_ have the large-pollset, then
you configure for it.
> > > I suspect that rebuilding the abstract pollset (apr_pollfd_t
array) in
> > > its entirety after calling poll() is harmful to Apache, which is
only
> > > going to process the first match.
> >
> > I am unable to parse this at all. If you are talking about the
current
> > implementation, then one of the advantages is that you don't need to
do
> > that anymore.
>
> Here is the code I referred to as "rebuilding the abstract pollset
> (apr_pollfd_t array):"
>
> for (i = 0; i < num; i++) {
> aprset[i].rtnevents = get_revent(pollset[i].revents);
> }
>
> *yeah, calling from Apache to APR is more expensive than an internal
> APR call, but are we digging that deep to find the benefit?
This is a straight bit-mask check, and in most cases, can be optimized
out to a no-op. We have to write the optimization, but 99% of the time,
the function call can be removed. As for the first/all rtnevents
decision, Apache should be using all of the results. We don't
currently, but we could and should.
Re: [Request for comments] new poll API
Posted by Jeff Trawick <tr...@attglobal.net>.
"Ryan Bloom" <rb...@covalent.net> 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 with Apache.
I started off agreeing that the new implementation is faster for small
pollsets, but I'm not sure that is the case when you consider
steady-state operations. We save the overhead of the function call to
look up the returned events after the poll call but we pick up the
overhead of the internal call to get_event() just before poll() is
called.*
Hopefully everybody agrees that the current implementation is harmful
for big pollsets.
If APR had a small-pollset API and a big-pollset API, I suspect we'd
be better off in Apache just using the big-pollset API rather than
deciding at run-time which API to pick since implementing a choice
would likely introduce an extra function call which would erase any
small benefit of being able to use the small-pollset API.
> > I suspect that rebuilding the abstract pollset (apr_pollfd_t array) in
> > its entirety after calling poll() is harmful to Apache, which is only
> > going to process the first match.
>
> I am unable to parse this at all. If you are talking about the current
> implementation, then one of the advantages is that you don't need to do
> that anymore.
Here is the code I referred to as "rebuilding the abstract pollset
(apr_pollfd_t array):"
for (i = 0; i < num; i++) {
aprset[i].rtnevents = get_revent(pollset[i].revents);
}
*yeah, calling from Apache to APR is more expensive than an internal
APR call, but are we digging that deep to find the benefit?
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
RE: [Request for comments] new poll API
Posted by Ryan Bloom <rb...@covalent.net>.
> > > > 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 don't consider that a valid use-case for justifying the
simpler
> > > API. (An APR app should be using an APR timeout socket option for
> > > that situation.)
> >
> > Let me see if I understand. Apr_poll() is too slow for APR to use,
but
> > because you don't expect APR apps to use it too often, that is okay.
> > Sorry, that doesn't hold water.
>
> You are grasping for generalizations and taking a lot of liberties
> with the facts along the way.
Sorry, but I don't think so. The facts are simple. You said that
apr_poll was both too slow and too complex for use inside of APR. To
fix that, I re-implemented apr_poll() to resolve both of those issues.
Now, (because there is an infinitely fixable memory leak), we are
throwing out the re-write, and going back to the abstract type, which
was too slow and too complex for use inside of APR. So, where am I
mis-remembering?
> > > Like I said above, I'd first like to see a description of an APR
app
> > > that is harmed by doing the setup and using the accessor
functions.
> > > This should be helpful in determining how important it is to
support
> > > the simpler API flavor.
> >
> > Well, Greg Ames used to say all the time that apr_poll was seriously
> > hurting the performance of Apache.
>
> Are you suggesting that Apache is a use-case to support the simpler
> flavor? I'm not sure how.
>
> 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 with Apache.
> I suspect that rebuilding the abstract pollset (apr_pollfd_t array) in
> its entirety after calling poll() is harmful to Apache, which is only
> going to process the first match.
I am unable to parse this at all. If you are talking about the current
implementation, then one of the advantages is that you don't need to do
that anymore. If you are talking about the previous implementation,
then I really don't see which side of the discussion you are on.
Ryan
Re: [Request for comments] new poll API
Posted by Jeff Trawick <tr...@attglobal.net>.
"Ryan Bloom" <rb...@covalent.net> writes:
> > From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
> > "Ryan Bloom" <rb...@covalent.net> writes:
> >
> > > > From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
> > > >
> > > > Brian Pane <br...@apache.org> 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 use (only!)
> > > > > with very small sets of descriptors.
> > > >
> > > > Do we really need this API? What is the sort of APR application
> for
> > > > which the heavy-duty API is harmful?
> > >
> > > 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 don't consider that a valid use-case for justifying the simpler
> > API. (An APR app should be using an APR timeout socket option for
> > that situation.)
>
> Let me see if I understand. Apr_poll() is too slow for APR to use, but
> because you don't expect APR apps to use it too often, that is okay.
> Sorry, that doesn't hold water.
You are grasping for generalizations and taking a lot of liberties
with the facts along the way.
> > Like I said above, I'd first like to see a description of an APR app
> > that is harmed by doing the setup and using the accessor functions.
> > This should be helpful in determining how important it is to support
> > the simpler API flavor.
>
> Well, Greg Ames used to say all the time that apr_poll was seriously
> hurting the performance of Apache.
Are you suggesting that Apache is a use-case to support the simpler
flavor? I'm not sure how.
I suspect that rebuilding the native pollset (e.g., struct pollfd
array) every time apr_poll() is called is harmful to Apache.
I suspect that rebuilding the abstract pollset (apr_pollfd_t array) in
its entirety after calling poll() is harmful to Apache, which is only
going to process the first match.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
RE: [Request for comments] new poll API
Posted by Ryan Bloom <rb...@covalent.net>.
> From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
> "Ryan Bloom" <rb...@covalent.net> writes:
>
> > > From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
> > >
> > > Brian Pane <br...@apache.org> 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 use (only!)
> > > > with very small sets of descriptors.
> > >
> > > Do we really need this API? What is the sort of APR application
for
> > > which the heavy-duty API is harmful?
> >
> > 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 don't consider that a valid use-case for justifying the simpler
> API. (An APR app should be using an APR timeout socket option for
> that situation.)
Let me see if I understand. Apr_poll() is too slow for APR to use, but
because you don't expect APR apps to use it too often, that is okay.
Sorry, that doesn't hold water.
> Like I said above, I'd first like to see a description of an APR app
> that is harmed by doing the setup and using the accessor functions.
> This should be helpful in determining how important it is to support
> the simpler API flavor.
Well, Greg Ames used to say all the time that apr_poll was seriously
hurting the performance of Apache.
Ryan
Re: [Request for comments] new poll API
Posted by Jeff Trawick <tr...@attglobal.net>.
"Ryan Bloom" <rb...@covalent.net> writes:
> > From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
> >
> > Brian Pane <br...@apache.org> 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 use (only!)
> > > with very small sets of descriptors.
> >
> > Do we really need this API? What is the sort of APR application for
> > which the heavy-duty API is harmful?
>
> 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 don't consider that a valid use-case for justifying the simpler
API. (An APR app should be using an APR timeout socket option for
that situation.)
Like I said above, I'd first like to see a description of an APR app
that is harmed by doing the setup and using the accessor functions.
This should be helpful in determining how important it is to support
the simpler API flavor.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
RE: [Request for comments] new poll API
Posted by Ryan Bloom <rb...@covalent.net>.
> From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
>
> Brian Pane <br...@apache.org> 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 use (only!)
> > with very small sets of descriptors.
>
> Do we really need this API? What is the sort of APR application for
> which the heavy-duty API is harmful?
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.
Ryan
Re: [Request for comments] new poll API
Posted by Jeff Trawick <tr...@attglobal.net>.
Brian Pane <br...@apache.org> 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 use (only!)
> with very small sets of descriptors.
Do we really need this API? What is the sort of APR application for
which the heavy-duty API is harmful?
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: [Request for comments] new poll API
Posted by Brian Pane <br...@cnet.com>.
Jeff Trawick wrote:
>Brian Pane <br...@apache.org> 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 abstract data type, accessible only through
>> functions, so that we can do internal optimizations in the
>> future (like replacing poll with /dev/poll on supported
>> platforms).
>>
>>
>
>In the interest of making progress I think you need to go ahead with
>this and we can all deal with the details (i.e., stick in the old code
>with new names and other tweaks) over the next couple of days.
>
Okay, I'll implement and commit this later today
Brian
[PATCH] Re: [Request for comments] new poll API
Posted by Brian Pane <br...@apache.org>.
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 problems:
* It's missing a fallback implementation for systems without poll(2)
* The "add descriptor" function doesn't check for duplicates.
I did this on purpose: it's implemented as a simple append
so that addition runs in O(1) time. The long-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 <br...@apache.org> 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 abstract data type, accessible only through
>> functions, so that we can do internal optimizations in the
>> future (like replacing poll with /dev/poll on supported
>> platforms).
>>
>>
>
>In the interest of making progress I think you need to go ahead with
>this and we can all deal with the details (i.e., stick in the old code
>with new names and other tweaks) over the next couple of days.
>
>
>
Re: [Request for comments] new poll API
Posted by Jeff Trawick <tr...@attglobal.net>.
Brian Pane <br...@apache.org> 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 abstract data type, accessible only through
> functions, so that we can do internal optimizations in the
> future (like replacing poll with /dev/poll on supported
> platforms).
In the interest of making progress I think you need to go ahead with
this and we can all deal with the details (i.e., stick in the old code
with new names and other tweaks) over the next couple of days.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: AF_UNIX sockets in APR...
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Jul 30, 2002 at 05:50:40PM -0700, Pier Fumagalli wrote:
> While at OSCON, I chatted about having AF_UNIX support in APR with a bunch
> of you, and I didn't hear any negative opinion from anyone...
>
> This would be so great for me, as it would ease my work with Java, in having
> a generic IO layer a little bit better than the current Java.IO and with an
> extensive support for all kinds of sockets...
>
> Are there strong feelings against it? Thanks...
+1 from me too, and I'd like to see this integrated with the apr_socket_t
stuff so that we parallel the bsd sockets as much as possible.
-aaron
Re: AF_UNIX sockets in APR...
Posted by Harrie Hazewinkel <ha...@mod-snmp.com>.
--On Wednesday, July 31, 2002 10:18 AM +0100 David Reid
<dr...@jetnet.co.uk> wrote:
> 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 -1 than -0...
Hmm, maybe some features of windows are worth adding. Not that I can
think of it. I don't even have a windows system.
>
> APR does not exist to scratch everyones individual itch. Sorry Pier.
Hmm, I have seen over the past that I also had some 'individual
itch' as you express it. Some of them were after a long time even
added since the more core Apache folks needed them or they simply
did not like to original idea which later changed.
Harrie
Internet Management Consulting
mailto:harrie@mod-snmp.com http ://www.mod-snmp.com/
-------------------------------------------------------------------
Author of MOD-SNMP, enabling SNMP management to the Apache server.
Re: AF_UNIX sockets in APR...
Posted by David Reid <dr...@jetnet.co.uk>.
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 -1 than -0...
We've talked about this before and we've said that what we're lacking is a
IPC api, not that we're lacking AF_LOCAL support.
APR does not exist to scratch everyones individual itch. Sorry Pier.
david
> On Tue, Jul 30, 2002 at 09:15:12PM -0700, Ryan Bloom wrote:
> > I have no problem implementing this feature, but do it right (which may
> > mean not using apr_socket_t), so that it is portable. We have enough
> > people who have asked for this feature, that not implementing it is kind
> > of stupid, but please, please, please, don't write the API such that it
> > absolutely can't work on Windows. That completely removes the goal of
> > APR. We have tried hard not to create functions that can't be written
> > on one of our platforms. Please don't add a type of communication that
> > isn't portable, that isn't useful in a portable library.
>
> I think the biggest problem is that we (at least myself) don't know
> what type of API would work for Win32. If someone with knowledge of
> how this might work on Win32 could describe an API, I think we can
> come up with an implementation in Unix. Whenever someone cares
> enough to implement the bits in Win32, they can add it.
>
> And, +1 to the "not implementing it is kind of stupid" as we've had
> this debate way too many times for my liking. -- justin
>
Re: AF_UNIX sockets in APR...
Posted by Ben Laurie <be...@algroup.co.uk>.
Justin Erenkrantz wrote:
> On Tue, Jul 30, 2002 at 09:15:12PM -0700, Ryan Bloom wrote:
>
>>I have no problem implementing this feature, but do it right (which may
>>mean not using apr_socket_t), so that it is portable. We have enough
>>people who have asked for this feature, that not implementing it is kind
>>of stupid, but please, please, please, don't write the API such that it
>>absolutely can't work on Windows. That completely removes the goal of
>>APR. We have tried hard not to create functions that can't be written
>>on one of our platforms. Please don't add a type of communication that
>>isn't portable, that isn't useful in a portable library.
>
>
> I think the biggest problem is that we (at least myself) don't know
> what type of API would work for Win32. If someone with knowledge of
> how this might work on Win32 could describe an API, I think we can
> come up with an implementation in Unix. Whenever someone cares
> enough to implement the bits in Win32, they can add it.
>
> And, +1 to the "not implementing it is kind of stupid" as we've had
> this debate way too many times for my liking. -- justin
If any of you guys are at Defcon, I'd be happy to discuss this.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Available for contract work.
Re: AF_UNIX sockets in APR...
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Jul 30, 2002 at 09:15:12PM -0700, Ryan Bloom wrote:
> I have no problem implementing this feature, but do it right (which may
> mean not using apr_socket_t), so that it is portable. We have enough
> people who have asked for this feature, that not implementing it is kind
> of stupid, but please, please, please, don't write the API such that it
> absolutely can't work on Windows. That completely removes the goal of
> APR. We have tried hard not to create functions that can't be written
> on one of our platforms. Please don't add a type of communication that
> isn't portable, that isn't useful in a portable library.
I think the biggest problem is that we (at least myself) don't know
what type of API would work for Win32. If someone with knowledge of
how this might work on Win32 could describe an API, I think we can
come up with an implementation in Unix. Whenever someone cares
enough to implement the bits in Win32, they can add it.
And, +1 to the "not implementing it is kind of stupid" as we've had
this debate way too many times for my liking. -- justin
Re: AF_UNIX sockets in APR...
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Jul 30, 2002 at 09:34:39PM -0700, Pier Fumagalli wrote:
> I agree with your sentiment, and frankly, I don't care whether we use
> apr_socket_t or not, as long as I can use the same functions to read and
> write to AF_UNIX and AF_INET sockets, because that's what I really need to
> do... :)
I don't see how we can do that unless you use apr_send/apr_sendv, which
both take apr_socket_t.
Since there are implementations of the bsd-style sockets on Windows
that support AF_UNIX/AF_LOCAL, I don't see why we don't just merge
that into our current apr_socket.h implementation.
-aaron
RE: AF_UNIX sockets in APR...
Posted by Ryan Bloom <rb...@covalent.net>.
> From: Pier Fumagalli [mailto:pier@betaversion.org]
>
> "Ryan Bloom" <rb...@covalent.net> wrote:
>
> > I have no problem implementing this feature, but do it right (which
may
> > mean not using apr_socket_t), so that it is portable. We have
enough
> > people who have asked for this feature, that not implementing it is
kind
> > of stupid, but please, please, please, don't write the API such that
it
> > absolutely can't work on Windows. That completely removes the goal
of
> > APR. We have tried hard not to create functions that can't be
written
> > on one of our platforms. Please don't add a type of communication
that
> > isn't portable, that isn't useful in a portable library.
>
> I agree with your sentiment, and frankly, I don't care whether we use
> apr_socket_t or not, as long as I can use the same functions to read
and
> write to AF_UNIX and AF_INET sockets, because that's what I really
need to
> do... :)
Okay, the read/write stuff is going to be hard to do, but maybe this is
the reason to finally implement the IO Layers.
Justin, as for the API, it should mirror the apr_socket_t API almost
exactly. I say almost, because there are a lot of functions in
apr_socket_t that aren't needed in AF_UNIX sockets. The only reason not
to use apr_socket_t, is that the Windows implementation is 100% separate
from the AF_INET implementation.
While a separate type will suck on Unix, it will speed up Windows and
make the implementation workable and readable on that platform.
Ryan
Re: AF_UNIX sockets in APR...
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Ryan Bloom" <rb...@covalent.net> wrote:
> I have no problem implementing this feature, but do it right (which may
> mean not using apr_socket_t), so that it is portable. We have enough
> people who have asked for this feature, that not implementing it is kind
> of stupid, but please, please, please, don't write the API such that it
> absolutely can't work on Windows. That completely removes the goal of
> APR. We have tried hard not to create functions that can't be written
> on one of our platforms. Please don't add a type of communication that
> isn't portable, that isn't useful in a portable library.
I agree with your sentiment, and frankly, I don't care whether we use
apr_socket_t or not, as long as I can use the same functions to read and
write to AF_UNIX and AF_INET sockets, because that's what I really need to
do... :)
Pier
RE: AF_UNIX sockets in APR...
Posted by Ryan Bloom <rb...@covalent.net>.
> > While the code is small, to the best of my knowledge, it is also not
> > portable. If it is portable, +1. If it is Unix only, -1.
>
> Well, it is not a "globally portable" feature... As fork(), for
instance,
> which doesn't exist on Windows, but still APR supports it.
Okay, I can accept that, except the while AF_UNIX isn't portable, the
concept can be written portably. Aaron, Will, and I had this
conversation a couple of months ago, and you can write domain
socket-like logic for Windows.
I do consider AF_UNIX different from fork(), because fork() is required
for any complex programs on Unix, and Windows just can't support it.
However, AF_UNIX can be written for Windows, albeit, it is a hack, and
requires a combination of sockets and named pipes.
> If APR provided me AF_UNIX, I would just use that... Please, don't
make
> the
> same stupid mistake that Java did. I'm bashing my head on the wall
> everytime
> I see the java.net classes because they are not extensible, and
because
> every time that someone wants to use AF_UNIX, they have to write it on
> their
> own... Ok, it doesn't work on Windows, but it works on another 2
> bazillions
> of UNIX implementations...
I have no problem implementing this feature, but do it right (which may
mean not using apr_socket_t), so that it is portable. We have enough
people who have asked for this feature, that not implementing it is kind
of stupid, but please, please, please, don't write the API such that it
absolutely can't work on Windows. That completely removes the goal of
APR. We have tried hard not to create functions that can't be written
on one of our platforms. Please don't add a type of communication that
isn't portable, that isn't useful in a portable library.
Ryan
Re: AF_UNIX sockets in APR...
Posted by Pier Fumagalli <pi...@betaversion.org>.
"rbb@apache.org" <rb...@apache.org> wrote:
> On Tue, 30 Jul 2002, Justin Erenkrantz wrote:
>
>> On Tue, Jul 30, 2002 at 05:50:40PM -0700, Pier Fumagalli wrote:
>>> While at OSCON, I chatted about having AF_UNIX support in APR with a bunch
>>> of you, and I didn't hear any negative opinion from anyone...
>>>
>>> This would be so great for me, as it would ease my work with Java, in having
>>> a generic IO layer a little bit better than the current Java.IO and with an
>>> extensive support for all kinds of sockets...
>>>
>>> Are there strong feelings against it? Thanks...
>>
>> As one of the people you talked to at OSCON, here's my +1 for adding
>> it. I've even submitted patches before to do this - the additional
>> code is quite small. -- justin
>
> While the code is small, to the best of my knowledge, it is also not
> portable. If it is portable, +1. If it is Unix only, -1.
Well, it is not a "globally portable" feature... As fork(), for instance,
which doesn't exist on Windows, but still APR supports it.
If AF_UNIX returned some APR_ENOIMPL under Windows, well, I'd be fine with
it. The PITA about not having it is that I have (and I've done that already)
to implement everything on my own, if I want to use AF_UNIX in those places
where I need it. I believe that having the advantage to use a specific
feature such as AF_UNIX (which is common to all platforms but Windows AFAIK,
dunno about OS/390, but...) in a portable way together with AF_INET sockets
IMO is FAR GREATER than checking for an APR_ENOIMPL return value when
someone under stupid Windows tries to create a socket with a path.
Look at my example here:
http://dev.betaversion.org/svn/jerry/head/jerry/java/org/betaversion/jerry/s
ocket/
I have a set of native acceptors (AF_???? server sockets), and right now,
for the stupid implementation, I cannot rely on APR, because it does not
support AF_UNIX...
http://dev.betaversion.org/svn/jerry/head/jerry/native/
So, I have to reimplement for "simplicity" also AF_INET, because in that
case, I have one "interface" (the stupid file descriptor), that works for
both of them, and I don't have to write my own little API different from
FDs, different from APR, different from everything to use FDs on AF_UNIX,
and APR on AF_INET...
If APR provided me AF_UNIX, I would just use that... Please, don't make the
same stupid mistake that Java did. I'm bashing my head on the wall everytime
I see the java.net classes because they are not extensible, and because
every time that someone wants to use AF_UNIX, they have to write it on their
own... Ok, it doesn't work on Windows, but it works on another 2 bazillions
of UNIX implementations...
Pretty please with sugar on top...
Pier (how many times can you count "stupid" in this email?)
Re: AF_UNIX sockets in APR...
Posted by rb...@apache.org.
On Tue, 30 Jul 2002, Justin Erenkrantz wrote:
> On Tue, Jul 30, 2002 at 05:50:40PM -0700, Pier Fumagalli wrote:
> > While at OSCON, I chatted about having AF_UNIX support in APR with a bunch
> > of you, and I didn't hear any negative opinion from anyone...
> >
> > This would be so great for me, as it would ease my work with Java, in having
> > a generic IO layer a little bit better than the current Java.IO and with an
> > extensive support for all kinds of sockets...
> >
> > Are there strong feelings against it? Thanks...
>
> As one of the people you talked to at OSCON, here's my +1 for adding
> it. I've even submitted patches before to do this - the additional
> code is quite small. -- justin
While the code is small, to the best of my knowledge, it is also not
portable. If it is portable, +1. If it is Unix only, -1.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
Re: AF_UNIX sockets in APR...
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Jul 30, 2002 at 05:50:40PM -0700, Pier Fumagalli wrote:
> While at OSCON, I chatted about having AF_UNIX support in APR with a bunch
> of you, and I didn't hear any negative opinion from anyone...
>
> This would be so great for me, as it would ease my work with Java, in having
> a generic IO layer a little bit better than the current Java.IO and with an
> extensive support for all kinds of sockets...
>
> Are there strong feelings against it? Thanks...
As one of the people you talked to at OSCON, here's my +1 for adding
it. I've even submitted patches before to do this - the additional
code is quite small. -- justin
Re: AF_UNIX sockets in APR...
Posted by Harrie Hazewinkel <ha...@lisanza.net>.
--On Tuesday, July 30, 2002 5:50 PM -0700 Pier Fumagalli
<pi...@betaversion.org> wrote:
> While at OSCON, I chatted about having AF_UNIX support in APR with a bunch
> of you, and I didn't hear any negative opinion from anyone...
>
> This would be so great for me, as it would ease my work with Java, in
> having a generic IO layer a little bit better than the current Java.IO
> and with an extensive support for all kinds of sockets...
>
> Are there strong feelings against it? Thanks...
All I would add is yes. +1 for adding this. I already asked/mentioned
this to some APR developers over a year ago. :-))
Harrie
Internet Management Consulting
mailto: harrie@lisanza.net http://www.lisanza.net/
--------------------------------------------------------------------
Author of MOD-SNMP, enabling SNMP management the Apache HTTP server
Re: AF_UNIX sockets in APR...
Posted by David Reid <dr...@jetnet.co.uk>.
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 would
destroy our abstractions (in that apr_socket_t wouldn't then be usable
across all platforms in the same manner).
Anyway, knock yourselves out.
david
----- Original Message -----
From: "Pier Fumagalli" <pi...@betaversion.org>
To: "APR Development List" <de...@apr.apache.org>
Sent: Wednesday, July 31, 2002 1:50 AM
Subject: AF_UNIX sockets in APR...
> While at OSCON, I chatted about having AF_UNIX support in APR with a bunch
> of you, and I didn't hear any negative opinion from anyone...
>
> This would be so great for me, as it would ease my work with Java, in
having
> a generic IO layer a little bit better than the current Java.IO and with
an
> extensive support for all kinds of sockets...
>
> Are there strong feelings against it? Thanks...
>
> Pier
>
>
AF_UNIX sockets in APR...
Posted by Pier Fumagalli <pi...@betaversion.org>.
While at OSCON, I chatted about having AF_UNIX support in APR with a bunch
of you, and I didn't hear any negative opinion from anyone...
This would be so great for me, as it would ease my work with Java, in having
a generic IO layer a little bit better than the current Java.IO and with an
extensive support for all kinds of sockets...
Are there strong feelings against it? Thanks...
Pier
Re: [Request for comments] new poll API
Posted by Brian Pane <br...@apache.org>.
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 revert the
current API (the one with the memory leak). I'll work on
this later today.
--Brian
RE: [Request for comments] new poll API
Posted by Sascha Schumann <sa...@apache.org>.
> 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
creation of a new API.
http://www.kegel.com/c10k.html#frameworks
lists some existing event-driven engines, including a C++
implementation by Dan Kegel.
http://libevent.sourceforge.net
The architecture is supposed to handle level/state triggered
event systems. It is still in the design phase, although
working code exists in the undernet ircd server.
http://www.acme.com/software/thttpd/
Thttpd has its own events abstraction, including (recurring)
timers and socket readiness (kqueue, poll, select).
- Sascha
RE: [Request for comments] new poll API
Posted by Bill Stoddard <bi...@wstoddard.com>.
>
> 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 descriptors. This is basically
> the current implementation, but with a limit on the number
> of descriptors that it will accept. With this limit, we
> can put the temporary pollfd array on the stack in apr_poll()
> to eliminate the memory leak.
>
> - A general-purpose poll API for larger sets of descriptors.
> This one is an abstract data type, accessible only through
> functions, so that we can do internal optimizations in the
> future (like replacing poll with /dev/poll on supported
> platforms).
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.
Bill