>What if the default in APR is to run in a separate address space*, and
in 
>places in Apache where on NetWare the child process should run in the
same 
>address space there is a call to the proper procattr manipulator to
override 
>the default so that the child runs in the same address space?  (and
ignore any 
>APR_ENOTIMPL retcode from that procattr manipulator so that no ifdef
NETWARE is 
>needed around the call)

   The is actually the behavior that we don't want on NetWare.  Running
CGI's or utilities like RotateLogs in a separate address space is very
painful and requires overhead and a performance hit that we don't want. 
On NetWare we need to default to the current address space.  BTW, an
address space on NetWare is, for the most part, very different than on
other platforms.  90% of what is running on the box, is running in the
same address space.
   When we implemented the CGIMapExtension directive to associate a CGI
extension with an executible (NetWare doesn't have a shell like BASH to
handle the associations) there is an optional parameter called "detach"
which allows the user to specify wheither the associated executible
should be run in the current address space or a separate address space. 
The default is the current address space.  

Brad


Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> [EMAIL PROTECTED] Tuesday, June 22, 2004 5:45:58 AM >>>
[EMAIL PROTECTED] wrote:
> clar        2004/06/21 12:11:56
> 
>   Modified:    .        Tag: APACHE_2_0_BRANCH STATUS
>   Log:
>   Removing bb proposal since it will require a major number bump
>   
>   Revision  Changes    Path
>   No                   revision
>   No                   revision
>   1.751.2.932 +1 -12     httpd-2.0/STATUS
>   
>   Index: STATUS
>  
===================================================================
>   RCS file: /home/cvs/httpd-2.0/STATUS,v
>   retrieving revision 1.751.2.931
>   retrieving revision 1.751.2.932
>   diff -u -r1.751.2.931 -r1.751.2.932
>   --- STATUS  20 Jun 2004 13:12:26 -0000      1.751.2.931
>   +++ STATUS  21 Jun 2004 19:11:56 -0000      1.751.2.932
>   @@ -77,17 +77,6 @@
>           hooks just like DSO modules can ["Philippe M. Chiasson"
<gozer cpan.org>]
>           +1: geoff
>    
>   -    *) mod_cgi: Added API call and new field in apr_procattr_t and
cgi_exec_info_t 
>   -       structures to support loading in current or new address
space for CGIs.
>   -       It fixes NetWare that is currently broken after changes
done to log.c r1.145.
>   -       modules/generators/mod_cgi.c r1.164
>   -       modules/generators/mod_cgi.h r1.14
>   -       modules/arch/netware/mod_netware r1.18
>   -       +1: jjclar, bnicholes
>   -       -0: nd
>   -       trawick: is minor mmn bump needed to reflect that API
structure was extended?
>   -       nd: same as mod_ssl.h issues. It's actually a major bump.

Jeff eventually needs to backport the use of a different cmdtype for
piped 
loggers in order to fix an outstanding PR and NetWare still needs to
create 
piped logger processes as expected and recover from a historical lack
of 
information provided to APR about whether or not the child process
should run 
within the same address space of the parent.

Surely there is some way to make this happen?

What if the default in APR is to run in a separate address space*, and
in 
places in Apache where on NetWare the child process should run in the
same 
address space there is a call to the proper procattr manipulator to
override 
the default so that the child runs in the same address space?  (and
ignore any 
APR_ENOTIMPL retcode from that procattr manipulator so that no ifdef
NETWARE is 
needed around the call)

This at least avoids adding a field to the end of the cgi structure
allocated 
by Apache and passed to modules implementing the optional function,
which (at 
the moment) a minority of people think requires a major bump.

*sounds natural to me; that also means that the default is the same on
all 
platforms -- run child in different address space

Reply via email to