Review Request: Do not wait for remaining Dr.Konqi instances without timeout when ending the KDE session

George Kiagiadakis kiagiadakis.george at gmail.com
Sun Dec 23 10:40:06 GMT 2012



> On Dec. 23, 2012, 10:27 a.m., Jekyll Wu wrote:
> > Ping? If there is no strong objection, I will push the proposed change (timeout adjusted to 15min) tomorrow so that it can catch 4.9.5

I'd say go ahead and commit it. It's better than the previous situation.


- George


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107657/#review23891
-----------------------------------------------------------


On Dec. 10, 2012, 8:16 a.m., Jekyll Wu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107657/
> -----------------------------------------------------------
> 
> (Updated Dec. 10, 2012, 8:16 a.m.)
> 
> 
> Review request for kde-workspace and George Kiagiadakis.
> 
> 
> Description
> -------
> 
> The existing code in startkde waits for Dr.Konqi instances to finish their jobs (saving or reporting the backtrace). That is good, since it make it possible to report crashes during the logout/shutdown procedure. But waiting for Dr.Konqi without timeout is not good:
> 
>   * When users comes back to their computers hours later, they can hardly remember their working context when trying to logout/shutdown previously.  I wouldn't expect those annoyed users are willing or able to create useful report under that situation.
> 
>   * It wastes power ...
> 
> 
> Some users suggest Dr.Konqi should implement a timeout feature, and one user even provides a patch (I tried). However, I don't think that timeout should be done within Dr.Konqi :
> 
> 
>    * It is not that Dr.Konqi intentionally blocks the procedure. It is the opposite, where startkde itself decides to wait for Dr.Konqi and block itself. So logically, the timeout should be done in startkde, not in Dr.Konqi. 
> 
>    * If the timeout is done in Dr.Konqi, then Dr.Konqi should only enable that timeout when the system is in the logout/shutdown procedure. 
> 
>      That user provided patch clearly doesn't consider that, and the result is if something (like kded) crashes when my system is idle and I'm away, then I won't even know kded has crashed when I comes back hours later.
> 
>      And detecting "whether the system is in the produce of logout/shutdown" is tricky. It can check whether org.kde.ksmserver is still reachable, but that only applies to a KDE session. So Dr.Konqi should add extra code to check whether it is running in a KDE session , whether ksmserver has gone, and the timeout itself. That sounds unnecessary extra work.
> 
> 
> So I propose startkde should add a timeout. The patch uses hardcoded 1 hour ( I think that is already long enough, or maybe still too long) as the timeout. Not sure whether it is worthwhile to make the timeout configurable at compile time or runtime.
> 
> 
> The only downside is some backtrace might be lost. But I don't think that is a big deal. Crashes during shutdown are rare cases nowadays(I hope I'm right), and users noticing those crashes only hours later are the rare case in rare cases (but very annoying).  
> 
> 
>  
> 
> 
> This addresses bug 126073.
>     http://bugs.kde.org/show_bug.cgi?id=126073
> 
> 
> Diffs
> -----
> 
>   startkde.cmake dc6f050 
> 
> Diff: http://git.reviewboard.kde.org/r/107657/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Jekyll Wu
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20121223/b272c84b/attachment.htm>


More information about the kde-core-devel mailing list