I do not like |fork|. I don't think that we are forking in the classic sense.
Lets just call this Launch? I think that it is high level enough to satisfy
everyone? (unless you are a unix hacker, and I am sure that this term will
upset you...)
Also, I do not want to use the term synchronous. Passing false, to me, would
indicate that I could get some callback. Either the functions blocks or return
immediately.
thoughts?
Samir Gehani wrote:
> Made some nomenclature suggestions in the revised, attached draft of
> nsIProcess.idl. I believe it is common to spawn a thread and fork a
> process. Hence, suggested fork() instead of spawn(). (Techincally, we
> the implementation behvior suggested here indicates the API should be
> forkAndExec() but I think that might be too platform specific; simple
> fork() gets the point across.) Suggested renaming 'block' to
> 'synchronous'.
>
> In addition, for synchronous processes XPInstall needs to access the
> exit value. I've suggested adding a readonly attribute along those lines.
>
> This functionality looks like it will suffice for XPInstall. Maybe
> other potential clients (plugins, OJI?) may want to review the interface.
> ~Samir
>
> Doug Turner wrote:
>
> > I think that this would be a good interface to have. Do you and Samir
> > want to put together an interface which has all the basic attributes of a
> > process? Don't worry too much about where it belongs in xpcom, that will
> > come during the implemention.
> >
> > I think that we may also need some kind of nsIProcessService which can
> > allow one to cycle through the process list and return nsIProcess's.
> >
> > I have attached a first draft of the nsIProcess idl. It still needs alot
> > of doxygen love, please comment.
> >
> >
> > Don Bragg wrote:
> >
> >
> >> Hi Brendan,
> >> Your suggestion about the creation of nsIProcess in lieu of changing
> >> Spawn brings up a question. Where would nsIProcess belong? Samir
> >> Gehani and I were discussing this and a likely place is xpcom/threads.
> >> I know that Scott Collins is the owner of the overall XPCOM but do you
> >> know if there's someone who should own this specifically? Or, if you
> >> don't think it belongs in threads where would you suggest?
> >>
> >> I want to make sure all the correct players are involved here.
> >>
> >> Thanks Brendan,
> >> -Don
> >>
> >> --
> >> The cardiologist's diet: If it tastes good, spit it out.
> >> nsIProcess.idl
> >>
> >> Content-Type:
> >>
> >> application/x-unknown-content-type-idlfile
> >> Content-Encoding:
> >>
> >> base64
> >>
> >>
>
> ------------------------------------------------------------------------
> /* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*-
> *
> * The contents of this file are subject to the Netscape Public
> * License Version 1.1 (the "License"); you may not use this file
> * except in compliance with the License. You may obtain a copy of
> * the License at http://www.mozilla.org/NPL/
> *
> * Software distributed under the License is distributed on an "AS
> * IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
> * implied. See the License for the specific language governing
> * rights and limitations under the License.
> *
> * The Original Code is mozilla.org code.
> *
> * The Initial Developer of the Original Code is Netscape
> * Communications Corporation. Portions created by Netscape are
> * Copyright (C) 1998 Netscape Communications Corporation. All
> * Rights Reserved.
> *
> * Contributor(s):
> */
>
> interface nsIFile;
>
> [scriptable, uuid(3ed86dbe-d084-11d4-ba7a-00c04fa0d26b)]
> interface nsIProcess
> {
> void init(in nsIFile executable);
> void initWithPid(unsigned long pid);
>
> void kill(in unsigned long signal);
>
> void fork(in boolean synchronous,
> [array, size_is(count)] in string args,
> in unsigned long count,
> out unsigned long pid);
>
> attribute readonly nsIFile location;
> attribute readonly unsigned long pid;
> attribute readonly string processName;
> attribute readonly unsigned long processSignature;
> attribute readonly unsigned long exitValue;
> };
