You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Brad Nicholes <BN...@novell.com> on 2004/06/14 17:19:33 UTC
Q: apr_procattr_xxx() API (was: cvs commit: apr/include
apr_thread_proc.h)
Is there a reason why the apr_procattr APIs were implemented as
apr_procattr_xxx_set (apr_procattr_t*, value)
rather than
apr_procattr_set (apr_procattr_t*, APR_xxx_ATTR, value, ...)
It seems like the second approach would make it easier for a platform
to extent the apr_procattr_t structure without having to add a new API
each time, just to have the new API become a no-op for every other
platform.
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
>>> Jeff Trawick <tr...@attglobal.net> Friday, June 11, 2004 2:47:42
PM >>>
clar@apache.org wrote:
> clar 2004/06/11 13:13:19
>
> Modified: include apr_thread_proc.h
> Log:
> Added NetWare specific option in apr_cmdtype_e to start program in
a separate address space for cmdtype field in apr_procattr_t struct
>
> Revision Changes Path
> 1.106 +7 -4 apr/include/apr_thread_proc.h
>
> Index: apr_thread_proc.h
>
===================================================================
> RCS file: /home/cvs/apr/include/apr_thread_proc.h,v
> retrieving revision 1.105
> retrieving revision 1.106
> diff -u -r1.105 -r1.106
> --- apr_thread_proc.h 10 Jun 2004 10:57:24 -0000 1.105
> +++ apr_thread_proc.h 11 Jun 2004 20:13:19 -0000 1.106
> @@ -42,10 +42,13 @@
> */
>
> typedef enum {
> - APR_SHELLCMD, /**< use the shell to invoke the program
*/
> - APR_PROGRAM, /**< invoke the program directly, no
copied env */
> - APR_PROGRAM_ENV, /**< invoke the program, replicating our
environment */
> - APR_PROGRAM_PATH /**< find program on PATH, use our
environment */
> +#ifdef NETWARE
> + APR_PROGRAM_ADDRSPACE, /**< invoke the program in its own
address space */
> +#endif
why wouldn't that be a separate process attribute? quite enough (too
much?)
characteristics specified via cmdtype attribute already
consider:
apr_procattr_shared_as_set(apr_procattr_t *attr, int allow_shared_as);
if allow_shared_as is non-zero, then implementation can possibly run
the
command in same address space as parent (everywhere but NetWare would
have that
a no-op)...
Re: Q: apr_procattr_xxx() API (was: cvs commit: apr/include apr_thread_proc.h)
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Jun 14, 2004 at 09:19:33AM -0600, Brad Nicholes wrote:
> Is there a reason why the apr_procattr APIs were implemented as
>
> apr_procattr_xxx_set (apr_procattr_t*, value)
>
> rather than
>
> apr_procattr_set (apr_procattr_t*, APR_xxx_ATTR, value, ...)
Because the different accessors take different numbers and type sof
parameters, you'd literally have to use "..." and varargs there, which
loses type-safety, and...
> It seems like the second approach would make it easier for a platform
> to extent the apr_procattr_t structure without having to add a new API
> each time, just to have the new API become a no-op for every other
> platform.
...is certainly more effort than having to copy'n'paste an APR_ENOTIMPL
stub a few times.
joe
Re: Q: apr_procattr_xxx() API (was: cvs commit: apr/include
apr_thread_proc.h)
Posted by rb...@rkbloom.net.
On Mon, 14 Jun 2004, Brad Nicholes wrote:
> Is there a reason why the apr_procattr APIs were implemented as
>
> apr_procattr_xxx_set (apr_procattr_t*, value)
>
> rather than
>
> apr_procattr_set (apr_procattr_t*, APR_xxx_ATTR, value, ...)
>
> It seems like the second approach would make it easier for a platform
> to extent the apr_procattr_t structure without having to add a new API
> each time, just to have the new API become a no-op for every other
> platform.
I did it that way to get type-safety for the arguments.
Ryan