On 12 March 2013 08:25, Enrico Tröger enrico.troeger@uvena.de wrote:
Hey Lex,
did you intentionally answered off-list?
Nah, your mail was to list and cc me, so the "smart" mailer chose to reply to you, and its too early in the morning for me to notice :)
This cced to the list for the record :)
I don't know if anybodys memory is good enough to remember why the comment was thought to be correct (it was 2006 when it was committed).
Perhaps it was a misunderstanding -- signals sent to the parent will hit the child process, but not the other way around. (If it did, kill %1 in your shell
Without having checked the whole history, I'm pretty much sure I wrote the comment and so also chose SIGQUIT. I vaguely remember some issues with the signals sent to the child processes and then Geany suddenly quit because it also received the signal or at least it seemed so to me. Well, it was back in 2006. It might also be that the behaviour I experienced was caused by another bug and I misinterpreted it and wrongly related it to the sent signal. As long as SIGTERM reliably works, I'd be fine with. I'd say now is a good time to check it in since 1.23 is just out and now master is allowed to new cool stuff again :).
Yeh, I nearly committed it directly on that basis, but eventually decided to be my usual cautious self :)
If it helps and no problems are to be expected, why not. As long as the change is not in master, nobody will test it :).
One day someone will re-write Geany's terminate handler to be legal and Geany will do the same :)
Ah nice, you do volunteer for that task!
"Some day" and when we figure out how to safely save a file using only write, not even fwrite is allowed so none of our existing file write methods is allowed. :(
I don't know either :(.
Not forgetting that we can't use g_convert because we don't know what system calls it uses, so its not gonna be easy to save any non-utf-8 encoding. Maybe the config & project files only?
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Le 11/03/2013 22:36, Lex Trotman a écrit :
On 12 March 2013 08:25, Enrico Tröger enrico.troeger@uvena.de wrote:
Hey Lex,
did you intentionally answered off-list?
Nah, your mail was to list and cc me, so the "smart" mailer chose to reply to you, and its too early in the morning for me to notice :)
This cced to the list for the record :)
> I don't know if anybodys memory is good enough to remember why the > comment was thought to be correct (it was 2006 when it was committed). [...]
I don't know anything about that, but I don't see a reason why kill()ing the child would mean any harm to us, so I guess it's ok.
One day someone will re-write Geany's terminate handler to be legal and Geany will do the same :)
Ah nice, you do volunteer for that task!
"Some day" and when we figure out how to safely save a file using only write, not even fwrite is allowed so none of our existing file write methods is allowed. :(
I don't know either :(.
Not forgetting that we can't use g_convert because we don't know what system calls it uses, so its not gonna be easy to save any non-utf-8 encoding. Maybe the config & project files only?
That's not the way to go. IIUC what everybody does is triggering something in the real program flow from the handler. E.g. write something to a pipe that is monitored by the main loop, and then the main loop would do the real handling. That don't seem so hard to implement, is it? BTW, don't the GLib have something like that already?
https://developer.gnome.org/glib/unstable/glib-UNIX-specific-utilities-and-i...
looks just fine, is there a problem with it? Ah crap, I read "since 2.30". But it's probably not that hard to implement on older versions ourselves, even if it simply means to borrow the relevant code…
Whatever. Cheers, Colomban
[...]
That's not the way to go. IIUC what everybody does is triggering something in the real program flow from the handler. E.g. write something to a pipe that is monitored by the main loop, and then the main loop would do the real handling. That don't seem so hard to implement, is it?
Well, IIRC its been proposed before, but nobody has been bothered to do it. :)
BTW, don't the GLib have something like that already?
https://developer.gnome.org/glib/unstable/glib-UNIX-specific-utilities-and-i...
looks just fine, is there a problem with it? Ah crap, I read "since 2.30".
Yeah, IIRC thats the sticking point we got to last time it was discussed :)
But it's probably not that hard to implement on older versions
ourselves, even if it simply means to borrow the relevant code…
As Enrico said, "Glad you volunteered" :)
A final comment is that since SIGTERM is generated by desktop environments when logging out, the whole handling and saving needs to be *fast* because the DEs don't seem to be very patient before they sigkill the process, and that can lose file contents when the save is partly complete.
Cheers Lex
Whatever. Cheers, Colomban _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Le 11/03/2013 23:42, Lex Trotman a écrit :
[...]
But it's probably not that hard to implement on older versions ourselves, even if it simply means to borrow the relevant code…
As Enrico said, "Glad you volunteered" :)
Nah, it doesn't work, you aren't Enrico ;)
A final comment is that since SIGTERM is generated by desktop environments when logging out, the whole handling and saving needs to be *fast* because the DEs don't seem to be very patient before they sigkill the process, and that can lose file contents when the save is partly complete.
I don't think handling SIGTERM is really the way to go handling desktop logout. To do this right one has to be able to ask the user for her unsaved files, and this has to pause the logout process. But I won't start talking about this because we have 2 guys that implemented thins about desktop logout handling and I don't want to bring the topic back, because I don't want to work on this :) Although it'd probably be cool to integrate some of the work.
Cheers, Colomban