Re: Re: Re: Re: how to control a process programmatically

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Michele Calgaro via trinity-devel wrote:


>> 
>> 
> In brief, fork creates a "duplicate process" but with different memory
> areas and then you have two processes continuing from the same point in
> the code. Usually the code will do different things depending on whether
> it is the parent process or the child one. In details, it is a bit more
> complex than what I described, but the ultimate idea is as above.
> 
> - --no-fork is usually good when you want to attach gdb to debug a
> problem, since you will not need to worry about separate forked processes.
> 

Thank you I already was that far with the general understanding. The
question is more about how it works from within KUniqueApplication, because
I have the feeling that the key is hidden there.
When it forks, it forks from the shell or similar.

For example


bool TestApp::startSomeProcess()
{

        TQProcess *someProcess = new TQProcess(TQString("apptorun"), this);
        if (!someProcess->start())
                return false;
        kdDebug() << k_funcinfo << someProcess->processIdentifier() << endl;
        return true;
}

Prints TestApp::startSomeProcess()]  4885

ps -A | grep apptorun
 4886 pts/13   00:00:00 apptorun


Why the other pid?

> According to processIdentifier() documentation, -1 is returned if no
> process is associated with the TQProcess object you are using. I think a
> "ps" or "pidof" is an easier way to go.
> 

yes it bothers me only that it does not return the pid that I was expecting
to see.

Also the lessons learned is important. I definitely want to use it
without --nofork. This way, it is guaranteed that no other instance will
run.

I wonder how this behaves in a multiuser environment. My understanding is
that it will be the same. if another user tries to start this application,
he will receive the message that this is already running. 

Complicated. It looks to me the one user that starts the parent application
(it is also kuinque) can fork this sub process and another user will be not
able to start or control either. Hmm if this was on my use case list ... I
haven't thought so far yet. I think I wanted to have parent application not
unique - each user can run a copy and the subprocess can be started by only
one user.
I think the discussion helped me understand this.

regards

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQSgzx3AlTPl6H9U20Dx7rjNn7FqUAUCXcHtywAKCRDx7rjNn7Fq
UL4iAPwNyM31kjVeAKNeUaKYRdCt5oKIXkgVq4BoKr4to/6/qgD/XiH15LuE1TKT
bXjBvac1YgiHZVdjTIoJGibalGQaPF4=
=rnEg
-----END PGP SIGNATURE-----


---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe@xxxxxxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: trinity-devel-help@xxxxxxxxxxxxxxxxxxxxxxxxxx
Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting




[Index of Archives]     [Trinity Users]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [KDE]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]     [Trinity Desktop Environment]

  Powered by Linux