[GRASS-dev] stop button in GUI?
Michael Barton
Michael.Barton at asu.edu
Fri Jun 15 22:16:50 PDT 2012
On Jun 15, 2012, at 9:08 PM, Glynn Clements wrote:
>
> Anna Kratochvílová wrote:
>
>>> There is a "stop" button in the GUI of all modules. When I press it, the
>>> GUI dialog returns to a state where I can reinitiate the module process. But
>>> looking in my system monitor, the old process is still continuing.
>
> Is it actually running, or is it a zombie?
It is using a lot of CPU cycles and memory. These values change as if it were still running. Running and stopping the module again produces a second process showing up in the system monitor using more CPU cycles and memory, etc. So I don't think it is a zombie.
>
>> and then line 578:
>> self.module.kill()
>> which doesn't work. I tried to call terminate(), for my Ubuntu it
>> works, however I have no idea why.
>
> For a subprocess.Popen object, the only difference between .kill() and
> .terminate() is that the former sends SIGKILL (which cannot be caught)
> while the latter sends SIGTERM (which can be caught).
>
> However, gcmd defines its own Popen class, derived from
> subprocess.Popen, which overrides the .kill() method in an attempt to
> terminate the entire process group:
>
> def kill(self):
> """!Try to kill running process"""
> if subprocess.mswindows:
> import win32api
> handle = win32api.OpenProcess(1, 0, self.pid)
> return (0 != win32api.TerminateProcess(handle, 0))
> else:
> try:
> os.kill(-self.pid, signal.SIGTERM) # kill whole group
> except OSError:
> pass
>
> However: subprocess.Popen() doesn't create a new process group for the
> child, so self.pid won't be a process group ID (PGID), so
> os.kill(-self.pid, ...) won't actually do anything.
>
> Also, it uses SIGTERM rather than SIGKILL, and silently ignores any
> exceptions.
>
> If it's desired to make the "stop" button kill the child process and
> all of its descendents, the child process must be explicitly put into
> a separate process group with os.setpgid() or os.setpgrp(). This must
> be done after the fork() but before the execve(); it should be
> possible to do this using the preexec_fn argument to the Popen
> constructor.
>
> OTOH, it might be better to just remove the overridden .kill() method
> and live with the fact that any descendents of child processes won't
> necessarily be terminated by the "stop" button (although in most
> cases, any descendents will terminate as a consequence of their parent
> terminating).
This seems an improvement over the prior behavior.
Michael
>
> --
> Glynn Clements <glynn at gclements.plus.com>
_____________________
C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &
University Consortium for Atmospheric Research
303-497-2889 (voice)
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
More information about the grass-dev
mailing list