You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Justin Erenkrantz <je...@ebuilt.com> on 2001/07/24 18:08:06 UTC
Re: [PATH] MPMT single acceptor patch
[ Adding dev@apr ]
On Tue, Jul 24, 2001 at 08:44:52AM -0700, Ryan Bloom wrote:
>
>
> This patch uses the original fdqueue.[ch] logic to implement the single acceptor, multiple
> worker logic in the threaded MPM. The original fdqueue logic can be found in apache-apr, but
> I have attached a copy to this message.
Should we APRize the fdqueue.[ch] code and stick it in apr-util? It
may be a little lightweight to merit that though. However, it also
relies on pthread condition variables. Maybe now would be a good
time to add condition variables to APR? Do other platforms have
the concept of condition variables?
(I know Aaron would love to see condition variables in APR.) -- justin
Re: [PATH] MPMT single acceptor patch
Posted by Ryan Bloom <rb...@covalent.net>.
On Tuesday 24 July 2001 09:08, Justin Erenkrantz wrote:
> [ Adding dev@apr ]
>
> On Tue, Jul 24, 2001 at 08:44:52AM -0700, Ryan Bloom wrote:
> > This patch uses the original fdqueue.[ch] logic to implement the single
> > acceptor, multiple worker logic in the threaded MPM. The original
> > fdqueue logic can be found in apache-apr, but I have attached a copy to
> > this message.
>
> Should we APRize the fdqueue.[ch] code and stick it in apr-util? It
> may be a little lightweight to merit that though. However, it also
> relies on pthread condition variables. Maybe now would be a good
> time to add condition variables to APR? Do other platforms have
> the concept of condition variables?
>
> (I know Aaron would love to see condition variables in APR.) -- justin
Yes, this should be APR'ized. It was harder to do that than it was to just post the code.
The queue logic probably doesn't belong in apr-util though. It is pretty specific to Apache,
and abstracting it out would most likely require more mutexes, that we want to avoid.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: [PATH] MPMT single acceptor patch
Posted by Ryan Bloom <rb...@covalent.net>.
On Tuesday 24 July 2001 09:08, Justin Erenkrantz wrote:
> [ Adding dev@apr ]
>
> On Tue, Jul 24, 2001 at 08:44:52AM -0700, Ryan Bloom wrote:
> > This patch uses the original fdqueue.[ch] logic to implement the single
> > acceptor, multiple worker logic in the threaded MPM. The original
> > fdqueue logic can be found in apache-apr, but I have attached a copy to
> > this message.
>
> Should we APRize the fdqueue.[ch] code and stick it in apr-util? It
> may be a little lightweight to merit that though. However, it also
> relies on pthread condition variables. Maybe now would be a good
> time to add condition variables to APR? Do other platforms have
> the concept of condition variables?
>
> (I know Aaron would love to see condition variables in APR.) -- justin
Yes, this should be APR'ized. It was harder to do that than it was to just post the code.
The queue logic probably doesn't belong in apr-util though. It is pretty specific to Apache,
and abstracting it out would most likely require more mutexes, that we want to avoid.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: [PATH] MPMT single acceptor patch
Posted by Aaron Bannert <aa...@ebuilt.com>.
On Tue, Jul 24, 2001 at 02:39:53PM -0500, William A. Rowe, Jr. wrote:
> From: "Aaron Bannert" <aa...@ebuilt.com>
> Sent: Tuesday, July 24, 2001 12:35 PM
>
> > Will the experts on each non- or semi-POSIX system please comment on if
> > these concepts are implementable? At this point I'm ignoring issues like
> > PROCESS_SHARED vs PROCESS_PRIVATE, since I think at first simply providing
> > "intraprocess" conditions would give us a huge benefit.
>
> Doug's implementation looks pretty slick for Win32, I presume OS2 will have
> no problems whatsoever.
I just looked through and it looks great. I'd like to present a patch
(well, a bunch of new files) that fits this into APR, but there is
the issue of what to do with apr_lock_t. I'd prefer keeping the
function names (s/ap_/apr_/) from Doug's implementation rather than
fooling around with the one-lock-fits-all apr_lock_t. Objections?
(I'm still wanting/willing to separate apr_lock_t into finer-grain
lock types, and this gets us going in that direction.)
-aaron
Re: [PATH] MPMT single acceptor patch
Posted by Aaron Bannert <aa...@ebuilt.com>.
On Tue, Jul 24, 2001 at 02:39:53PM -0500, William A. Rowe, Jr. wrote:
> From: "Aaron Bannert" <aa...@ebuilt.com>
> Sent: Tuesday, July 24, 2001 12:35 PM
>
> > Will the experts on each non- or semi-POSIX system please comment on if
> > these concepts are implementable? At this point I'm ignoring issues like
> > PROCESS_SHARED vs PROCESS_PRIVATE, since I think at first simply providing
> > "intraprocess" conditions would give us a huge benefit.
>
> Doug's implementation looks pretty slick for Win32, I presume OS2 will have
> no problems whatsoever.
I just looked through and it looks great. I'd like to present a patch
(well, a bunch of new files) that fits this into APR, but there is
the issue of what to do with apr_lock_t. I'd prefer keeping the
function names (s/ap_/apr_/) from Doug's implementation rather than
fooling around with the one-lock-fits-all apr_lock_t. Objections?
(I'm still wanting/willing to separate apr_lock_t into finer-grain
lock types, and this gets us going in that direction.)
-aaron
Re: [PATH] MPMT single acceptor patch
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Aaron Bannert" <aa...@ebuilt.com>
Sent: Tuesday, July 24, 2001 12:35 PM
> Will the experts on each non- or semi-POSIX system please comment on if
> these concepts are implementable? At this point I'm ignoring issues like
> PROCESS_SHARED vs PROCESS_PRIVATE, since I think at first simply providing
> "intraprocess" conditions would give us a huge benefit.
Doug's implementation looks pretty slick for Win32, I presume OS2 will have
no problems whatsoever.
Bill
Re: [PATH] MPMT single acceptor patch
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Aaron Bannert" <aa...@ebuilt.com>
Sent: Tuesday, July 24, 2001 12:35 PM
> Will the experts on each non- or semi-POSIX system please comment on if
> these concepts are implementable? At this point I'm ignoring issues like
> PROCESS_SHARED vs PROCESS_PRIVATE, since I think at first simply providing
> "intraprocess" conditions would give us a huge benefit.
Doug's implementation looks pretty slick for Win32, I presume OS2 will have
no problems whatsoever.
Bill
Re: [PATH] MPMT single acceptor patch
Posted by Aaron Bannert <aa...@ebuilt.com>.
On Tue, Jul 24, 2001 at 09:08:06AM -0700, Justin Erenkrantz wrote:
> On Tue, Jul 24, 2001 at 08:44:52AM -0700, Ryan Bloom wrote:
> > This patch uses the original fdqueue.[ch] logic to implement the single acceptor, multiple
> > worker logic in the threaded MPM. The original fdqueue logic can be found in apache-apr, but
> > I have attached a copy to this message.
>
> Should we APRize the fdqueue.[ch] code and stick it in apr-util? It
> may be a little lightweight to merit that though. However, it also
> relies on pthread condition variables. Maybe now would be a good
> time to add condition variables to APR? Do other platforms have
> the concept of condition variables?
>
> (I know Aaron would love to see condition variables in APR.) -- justin
Of course I'd love to see condition variables in APR, and I think it
applies perfectly to this use case in httpd's threaded mpm, like this:
- start up a pool(*) of worker threads
- use rbb's listener thread to generate events by:
- poll()ing for POD events or connect()s on the socket
- POD events would be broadcast to all [sleeping] threads so they
could wake up and die.
- connect events could signal a single thread to wake up and handle the
request.
(* not to be confused with a memory allocator/scope pool)
Later we could add more fanciness by adding another thread to monitor the
number of threads waiting in the threadpool, and increase or decrease that
number as necessary to meet load)
I'm really only familiar with the posix concept of conditions, so I really
have no idea if we could map this functionality onto other systems like
OS2/Win32. To get the discussion going, here are the things we'd need to
support (if we decide to shadow POSIX):
- cond_wait(cond, mutex)
wait for a condition to occur on 'cond'. 'mutex' is expected to be already
locked, so cond_wait() must be able to atomically unlock 'mutex' and put
the calling thread to sleep.
- cond_signal(cond)
wakes up a thread that's waiting on 'cond'.
- cond_broadcast(cond)
wakes up all threads waiting on 'cond'.
- cond_timedwait(cond, mutex, timespec)
acts like cond_wait(), wakes up automatically when 'timespec' happens
(it's an absolute time)
[not sure if this one is necessary yet]
Will the experts on each non- or semi-POSIX system please comment on if
these concepts are implementable? At this point I'm ignoring issues like
PROCESS_SHARED vs PROCESS_PRIVATE, since I think at first simply providing
"intraprocess" conditions would give us a huge benefit.
-aaron
Re: [PATH] MPMT single acceptor patch
Posted by Aaron Bannert <aa...@ebuilt.com>.
On Tue, Jul 24, 2001 at 09:08:06AM -0700, Justin Erenkrantz wrote:
> On Tue, Jul 24, 2001 at 08:44:52AM -0700, Ryan Bloom wrote:
> > This patch uses the original fdqueue.[ch] logic to implement the single acceptor, multiple
> > worker logic in the threaded MPM. The original fdqueue logic can be found in apache-apr, but
> > I have attached a copy to this message.
>
> Should we APRize the fdqueue.[ch] code and stick it in apr-util? It
> may be a little lightweight to merit that though. However, it also
> relies on pthread condition variables. Maybe now would be a good
> time to add condition variables to APR? Do other platforms have
> the concept of condition variables?
>
> (I know Aaron would love to see condition variables in APR.) -- justin
Of course I'd love to see condition variables in APR, and I think it
applies perfectly to this use case in httpd's threaded mpm, like this:
- start up a pool(*) of worker threads
- use rbb's listener thread to generate events by:
- poll()ing for POD events or connect()s on the socket
- POD events would be broadcast to all [sleeping] threads so they
could wake up and die.
- connect events could signal a single thread to wake up and handle the
request.
(* not to be confused with a memory allocator/scope pool)
Later we could add more fanciness by adding another thread to monitor the
number of threads waiting in the threadpool, and increase or decrease that
number as necessary to meet load)
I'm really only familiar with the posix concept of conditions, so I really
have no idea if we could map this functionality onto other systems like
OS2/Win32. To get the discussion going, here are the things we'd need to
support (if we decide to shadow POSIX):
- cond_wait(cond, mutex)
wait for a condition to occur on 'cond'. 'mutex' is expected to be already
locked, so cond_wait() must be able to atomically unlock 'mutex' and put
the calling thread to sleep.
- cond_signal(cond)
wakes up a thread that's waiting on 'cond'.
- cond_broadcast(cond)
wakes up all threads waiting on 'cond'.
- cond_timedwait(cond, mutex, timespec)
acts like cond_wait(), wakes up automatically when 'timespec' happens
(it's an absolute time)
[not sure if this one is necessary yet]
Will the experts on each non- or semi-POSIX system please comment on if
these concepts are implementable? At this point I'm ignoring issues like
PROCESS_SHARED vs PROCESS_PRIVATE, since I think at first simply providing
"intraprocess" conditions would give us a huge benefit.
-aaron
Re: [PATH] MPMT single acceptor patch
Posted by Doug MacEachern <do...@covalent.net>.
On Tue, 24 Jul 2001, Justin Erenkrantz wrote:
> Should we APRize the fdqueue.[ch] code and stick it in apr-util? It
> may be a little lightweight to merit that though. However, it also
> relies on pthread condition variables. Maybe now would be a good
> time to add condition variables to APR? Do other platforms have
> the concept of condition variables?
>
> (I know Aaron would love to see condition variables in APR.) -- justin
mod_perl uses Perl's abstraction for condition variables, i would be
much happier using an apr version, since the code that makes use of
them is not specific to mod_perl or Perl. i had started to lift this out
into something for apr ages ago, but never submitted anything. i just put
the files here that might be useful as a reference:
http://apr.apache.org/~dougm/modperl_thread.c
http://apr.apache.org/~dougm/modperl_thread.h
Re: [PATH] MPMT single acceptor patch
Posted by Doug MacEachern <do...@covalent.net>.
On Tue, 24 Jul 2001, Justin Erenkrantz wrote:
> Should we APRize the fdqueue.[ch] code and stick it in apr-util? It
> may be a little lightweight to merit that though. However, it also
> relies on pthread condition variables. Maybe now would be a good
> time to add condition variables to APR? Do other platforms have
> the concept of condition variables?
>
> (I know Aaron would love to see condition variables in APR.) -- justin
mod_perl uses Perl's abstraction for condition variables, i would be
much happier using an apr version, since the code that makes use of
them is not specific to mod_perl or Perl. i had started to lift this out
into something for apr ages ago, but never submitted anything. i just put
the files here that might be useful as a reference:
http://apr.apache.org/~dougm/modperl_thread.c
http://apr.apache.org/~dougm/modperl_thread.h
Re: [PATH] MPMT single acceptor patch
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Tue, 24 Jul 2001 09:08:06 -0700, Justin Erenkrantz wrote:
>[ Adding dev@apr ]
>
>On Tue, Jul 24, 2001 at 08:44:52AM -0700, Ryan Bloom wrote:
>>
>>
>> This patch uses the original fdqueue.[ch] logic to implement the single acceptor, multiple
>> worker logic in the threaded MPM. The original fdqueue logic can be found in apache-apr, but
>> I have attached a copy to this message.
>
>Should we APRize the fdqueue.[ch] code and stick it in apr-util? It
>may be a little lightweight to merit that though. However, it also
>relies on pthread condition variables. Maybe now would be a good
>time to add condition variables to APR? Do other platforms have
>the concept of condition variables?
>From what I've seen so far, they're like event semaphores on OS/2 & Win32.
I haven't actually read any docs on pthread condition variables though so I
can't say for sure.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: [PATH] MPMT single acceptor patch
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Tue, 24 Jul 2001 09:08:06 -0700, Justin Erenkrantz wrote:
>[ Adding dev@apr ]
>
>On Tue, Jul 24, 2001 at 08:44:52AM -0700, Ryan Bloom wrote:
>>
>>
>> This patch uses the original fdqueue.[ch] logic to implement the single acceptor, multiple
>> worker logic in the threaded MPM. The original fdqueue logic can be found in apache-apr, but
>> I have attached a copy to this message.
>
>Should we APRize the fdqueue.[ch] code and stick it in apr-util? It
>may be a little lightweight to merit that though. However, it also
>relies on pthread condition variables. Maybe now would be a good
>time to add condition variables to APR? Do other platforms have
>the concept of condition variables?
>From what I've seen so far, they're like event semaphores on OS/2 & Win32.
I haven't actually read any docs on pthread condition variables though so I
can't say for sure.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------