Re: [Geany-Devel] spawn_kill_process TERM or KILL?
On 15-09-22 03:42 PM, Lex Trotman wrote:
On 23 September 2015 at 00:35, Dimitar Zhekov wrote:
Hi, all,
Should spawn_kill_process send a SIGTERM or SIGKILL to the child under *nix?
- SIGTERM lets the child exit gracefully, removing temporary files etc.
This says it all, blasting a process and possibly leaving the build
system in an unknown state is a "bad thing" (tm).
[...]
Agree SIGTERM sounds more polite. I think well behaved DEs (or is it in
the window manager?) will prompt you to really kill a process if it's
not responding, so we could leave that to them.
[...]
- the API name is "kill", not terminate.
Its too late to change it now if its in the API.
For now we could do something like:
/** @deprecated @see spawn_terminate_process() */
gboolean spawn_kill_process(GPid pid, GError **error) {
return spawn_terminate_process(pid, error);
}
Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] spawn_kill_process TERM or KILL?
On 23 September 2015 at 00:35, Dimitar Zhekov wrote: > Hi, all, > > Should spawn_kill_process send a SIGTERM or SIGKILL to the child under *nix? > > - SIGTERM lets the child exit gracefully, removing temporary files etc. This says it all, blasting a process and possibly leaving the build system in an unknown state is a "bad thing" (tm). Also consider the effect when there is more than one spawned process in the build, you may not kill them all, leave zombies, not clean up backend build servers etc. The build should be politely given the chance to clean up, since it might be designed to do so, we don't know. > > - the original build.c:kill_process from Geany <= 1.24 sends SIGTERM Yes, this has been discussed before, but I can't remember where. > > - the child may refuse to terminate on SIGTERM (or be unable to respond to > it because of blocking I/O) > > - under Windows, TerminateProcess() is an equivalent of SIGKILL, not SIGTERM Does Windows have a sigterm equivalent? We should not make Linux worse to match Windows. > > - the API name is "kill", not terminate. Its too late to change it now if its in the API. > > -- > E-gards: Jimmy > ___ > Devel mailing list > Devel@lists.geany.org > https://lists.geany.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] Hello!
Hi, I am an EE/CE engineering student with a little bit of experience in C. I want to get involved in the open source community and I have heard that Geany is a good starting point. I do not have an extensive knowledge of C, but I use C basics almost daily in MATlab, Arduino, and microprocessor applications that are translated to C. I am a very quick learner and I want to get more involved in developing/debugging the open source software that I use. I hope I can be of use to the Geany development community. Corey ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] spawn_kill_process TERM or KILL?
Hi, all, Should spawn_kill_process send a SIGTERM or SIGKILL to the child under *nix? - SIGTERM lets the child exit gracefully, removing temporary files etc. - the original build.c:kill_process from Geany <= 1.24 sends SIGTERM - the child may refuse to terminate on SIGTERM (or be unable to respond to it because of blocking I/O) - under Windows, TerminateProcess() is an equivalent of SIGKILL, not SIGTERM - the API name is "kill", not terminate. -- E-gards: Jimmy ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] SPAWN_LEAVE_STDIN_OPEN
Hi, all, It seems that one more spawn flag will be useful: SPAWN_LEAVE_STDIN_OPEN. Suppose that you need to send data to your child not constantly, but only from time to time (possibly after sending some startup data). You should to discard the initial stdin callback/source, to prevent it from being called when there is no data to send (and since the stdin channel is free, the callback is invoked constantly and raises high CPU usage). Normally you would reference the channel, remember it, return FALSE to discard the initial callback, and create a new callback/source each time you have data to send (glib does not allow re-attaching a removed source). The problem with the current implementation is, as soon you return FALSE, spawn shutdowns (closes) the channel completely. You may assume that g_io_channel_set_close_on_unref() will handle everything gracefully, but at least under Windows, if the child reads it's stdin until EOF (for example cat), so the channel must be closed explicitly on our end, glib will fail to auto-close it on unref (or even block? because the child is alive? I'm not sure about that). So, SPAWN_LEAVE_STDIN_OPEN tells spawn not to shutdown the stdin channel, because you may hold a reference to it. Unfortunately, I see no official way to verify the ref_count of a GIOChannel. Now, one can dup(g_io_channel_unix_get_fd(channel)), create and setup a new channel, and leave the original one to be closed (it works, I've checked), but that's seems unnecessarily complicated. Thoughts? Maybe I'm missing something? -- E-gards: Jimmy ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
