httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject PTH in APR
Date Sat, 10 Jul 1999 17:16:45 GMT

I am going to get in on this discussion.  I have been away for the last
few days, so I haven't said anything about putting pth into apr.  It isn't
going to happen anytime soon.  The plan is, I am going to put A user-land
thread library into apr, at somepoint in the future.  I do not know which
one, and I do not know when.  If pth is the best choice, that is the one
we will use.  If it makes the most sense to have compile time options,
that is what I will use.  Basically, there has been no work done on this,
and there won't be for a while.

Ryan

On Sat, 10 Jul 1999, Michael H. Voase wrote:

> Dean Gaudet wrote:
> > 
> > On Fri, 9 Jul 1999, Michael H. Voase wrote:
> > 
> > >       Pth is one of the reasons I started looking
> > > at this api mapping method . The issue that gets at me
> > > is that pth wont provide any benefit to SMP boxen . Once
> > > the scheduler starts , your stuck on one proccessor .
> > 
> > It would be easy to write an mpm which spawned multiple processes, and
> > used pth in each process.  That's what mpm is about.
> > 
> > >       If you guys are going to put pth in apr then
> > 
> > I don't know where ya got the idea we were putting pth in apr...
> > 
> > Dean
> 
> 	Arr ... phew . I was very concerned for
> a while there . Many humble appologies , from
> earlier correspondence I was under the mistaken
> impression that pth was going into apr ...
> 
> Consider the api switching idea duly scrapped.
> ( I didnt like the idea of it either .. I just
> thought I had no choice ;)
> 
> As for api mappings , I still contend that it would
> be usefull for a couple of unrelated reasons . 
>  
> 	The use of an api map and an
> appropriate header bundled with an mpm module
> would result in a thin api translation layer
> that can define what libs the application is
> using through the ap_* interface . This means
> that the application no longer needs to be aware
> of or directly connected to the underlying 
> support libs it is actually using . 
> 
> This would be usefull for rounding out the
> complete apache api so that there are no more
> direct OS calls in the apache web server 
> application . For those functions that are
> (generally) consistent on most platforms ,
> the macro could map such a function directly
> to an OS system call and avoid the expense of
> calling a wrapper function in apr . This
> could compliment apr by handing back an
> advantage to those platforms that are
> particularly compliant with posix
> standards .
> 
> Lastly as it stands , apache 2.0 comes very , very
> close to an open ended , generalised application
> framework . API mappings would come in handy for
> people porting applications to the apache framework .
> 
> Cheers Mik Voase.
> 
> -- 
> ----------------------------------------------------------------------------
>  /~\     /~\            CASTLE INDUSTRIES PTY. LTD.
>  | |_____| |            Incorporated 1969. in N.S.W., Australia
>  |         |            Phone +612 6567 1227 Fax +612 6567 1449
>  |   /~\   |            Web http://www.midcoast.com.au/~mvoase
>  |   [ ]   |            Michael H. Voase.  Director.
> ~~~~~~~~~~~~~~          Castle Industries - Industrial Strength
> Solutions.
> ----------------------------------------------------------------------------
> 

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	


Mime
View raw message