[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apr-dev
Subject:    Re: cvs commit: apr/threadproc/win32 proc.c
From:       Greg Stein <gstein () lyra ! org>
Date:       2002-01-29 19:57:35
[Download RAW message or body]

On Mon, Jan 28, 2002 at 11:35:20PM -0600, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <gstein@lyra.org>
> Sent: Monday, January 28, 2002 9:50 PM
>...
> > But it would also open up a combination that isn't possible --
> > APR_PROGRAM_PATH with env==[...]. In words that is, "search for the program
> > on PATH, and here is the environment to use." That combination isn't
> > available on Unix, at least.
> 
> Can we say APR_ENOTIMPL?  Seriously, Win32 always searches the program path
> if the executable (1st arg to CreateProcess) is NULL.  It executes a very 
> specific program if the 1st arg is given.  This part of your new schema is 
> great goodness.

See my note to Brian, re: using a cmdtype rather than at proc_create() time.

> But If I'm Not Mistaken [Read: I'm probably mistaken], exec() is essentially 
> a fork() -> load process -> run sequence [please correct me.]  There is nothing 
> keeping us from replacing the environment after we've done the fork(), is there?

The process is: fork() to duplicate the process (into a parent and child),
then the child process replaces itself by using exec(). The child then
starts running.

The environment is (typically) readonly, so it cannot be replaced after the
exec() occur.

>...
> > The enumerated type gives us the ability to specify the exact combinations
> > that are allowed to callers.
> 
> Ugh.  It is not exactly quaint, but I begin to see some value here.  Still,
> this just makes more sense as flags, if you ask me [who was asking :-?]  EVEN
> if we treat it as flags, but only allow specific combinations.  At least we
> can test them by bit to find specific logic rules.

I prefer the enumerations, but a set of flags would be acceptable. As long
as it is cmdtype_set() that returns the ENOTIMPL. proc_create() would simply
ignore/use the 'env' parameter as defined for the command type.

(it could also be acceptable to return an error if env is provided but not
being used; "error" also meaning an abort() is possible :-)

And in retrospect, I'd probably use APR_PROGRAM_INH_ENV or something to
indicate inheritence. APR_PROGRAM_ENV might indicate "use the environment
provided" which is opposite of the actual semantic :-)

>...
> I'm still with Brian, I think this is overkill.  I also agree with you, we
> need to pay attention to the docs :)  But the only think you can argue was
> passing NULL for env was undefined.  Its use-definition wasn't a bad one.

Not overkill, but to prevent illegal combinations. And detecting those
combinations at cmdtype_set type (rather than basing on 'env' at create
time) is still valid.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
[prev in list] [next in list] [prev in thread] [next in thread]