Review Request: Make Sonnet::Speller::setLanguage threadsafe, fixing segfaults in krunner

Thomas L├╝bking thomas.luebking at web.de
Mon Sep 10 12:06:48 BST 2012



> On Sept. 6, 2012, 12:29 p.m., David Faure wrote:
> > A number of comments on the implementation, but also a more general comment: does it even make sense to use a Speller in multiple threads, and to  change the language from one thread while another one is using the speller for spell-checking? It sounds like, even if a mutex/lock can prevent crashes, this is a weird thing to do anyway, since you have no idea at which point the spell-checking will switch to another language... could happen in the very middle of a sentence...
> > 
> > Maybe it would make more sense to "post" the language change operation to the spell-checking thread using the same mechanism as the one used to "post" spellchecking requests to it? (Disclaimer: I know nothing of the krunner architecture).
> 
> Simeon Bird wrote:
>     Thanks for the review. 
>     
>     I agree that this is a slightly weird thing to do, but, as you surmise, it was the only way I could think of to make the feature work properly. 
>     
>     As far as I understand it (from reading the documentation), the way krunner works is to call Plasma::AbstractRunner::match in a new thread for every runner every time input is entered. 
>     
>     So if I enter:
>     
>     "spell hello"
>     
>     I will be called with 's' 'sp' 'spe'...and so on until I get the whole match, without waiting for the previous threads to return. Thus match has to be thread-safe.
>     
>     The feature I'm trying to fix here is to be able to enter "spell french bonjour" and have it spell something. 
>     The runner is responsible for parsing the input and checking whether it should do anything else.
>     So we don't actually post spellchecking requests, we just post some input, and detect that we should spell-check, and change the language, by parsing strings. So I couldn't see a way to do this except to call Sonnet::Speller::setLanguage() in Plasma::AbstractRunner::match, 
>     which meant that for it to work I had to make match thread-safe. 
>     
>     Sorry. I'm open to suggestions if you have a better idea. 
>     
>     I've fixed your other comments in v2 of the diff, let me know if there is anything else.

would it not make more sense to just kill the pending (and now worthless?) thread instead (no idea how expensive this spellchecking is to be threaded) to not waste cpu on a result that will be ignored anyway?


- Thomas


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


On Sept. 9, 2012, 10:06 p.m., Simeon Bird wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106242/
> -----------------------------------------------------------
> 
> (Updated Sept. 9, 2012, 10:06 p.m.)
> 
> 
> Review request for kdelibs and Plasma.
> 
> 
> Description
> -------
> 
> Krunner's spellcheck plugin has been pretty broken since bd291d21f096a714a171e7af3a534ba345ca5659 (about two years ago) because it called Sonnet::Speller::setLanguage every time the spellchecker was invoked, which was (very much) not thread-safe.
> 
> This patch makes Sonnet::Speller::setLanguage threadsafe by protecting all access to the internal dict pointer using QReadWriteLock. 
> 
> A related review request is 106244, which adds more fixes to the spellcheck feature.
> 
> 
> This addresses bugs 264779 and 303831.
>     http://bugs.kde.org/show_bug.cgi?id=264779
>     http://bugs.kde.org/show_bug.cgi?id=303831
> 
> 
> Diffs
> -----
> 
>   kdecore/sonnet/speller.cpp b19e74d 
> 
> Diff: http://git.reviewboard.kde.org/r/106242/diff/
> 
> 
> Testing
> -------
> 
> Compiled, installed, used for a week or so, spellchecked a bunch of things.
> 
> 
> Thanks,
> 
> Simeon Bird
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120910/d41a5772/attachment.htm>
-------------- next part --------------
_______________________________________________
Plasma-devel mailing list
Plasma-devel at kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


More information about the kde-core-devel mailing list