[GCompris-devel] Mutex handling in Download manager

[JAZEIX Johnny]

Hi,

On 08/27/15 21:17, Holger Kaelberer wrote:
> Hi Johnny,
>
> On 27.08.2015 10:26, Johnny Jazeix wrote:
>> Hi,
>>
>> I found a potential deadlock in the DownloadManager.
>>
>> For some activities, we try to load two rcc in a row: for lang or
>> hangman, we need to load words and localized voices.
>>
>> What is actually done is to load the words.rcc and when loaded, we
>> load the voice.
>>
>> Coding speaking, on onStart activity, we call the registerResource for
>> words which locks the rcMutex. Then, as we have connected the
>> DownloadManager::resourceRegistered to the
>> activity.resourceRegistered, this one calls the Activity.start which
>> tries to load the localized voices which will call the
>> registerResource and try to lock the (already locked) rcMutex...
>
> Good catch! This can happen if the signal-slot connections are 
> DirectConnection-s, which seems to be the case if you experienced a 
> deadlock.
>
>>
>> Is there a good practice to avoid that or can we just unlock the mutex
>> before emitting the resourceRegister signal?
>
> rcMutex is there to protect registeredResources, therefore it is safe 
> to unlock it right after having modified it. Cf. attached patch, if 
> this fixes your issue, pls. commit.
>

This fixes the issue :). Commit: 
https://quickgit.kde.org/?p=gcompris.git&a=commit&h=e0ac0a25a496957d9413d69ad47e52f391df1807

>>
>> We could also, load the two rcc in the onStart method and waiting for
>> both rcc to be loaded to start the activity.
>
> Correct. Having a quick look at the lang branch I found in the kde git 
> (where is hangman, btw?), it seems complicated to serialize the 
> download-calls via the resourceRegistered signal. You should be able 
> to launch all your downloads via downloadResource() immediately, i.e. 
> in parallel and continue processing on resourceRegistered of the last 
> target resource. I had parallel downloads in mind when writing the 
> code, although did not test it yet, as we didn't have >1 rcc files in 
> the beginning. Could be the right time to give it a try ... ;-)
>

Oops I forgot the link, hangman is still in progress 
(https://github.com/clock21am/GCompris-qt/tree/exercise).

> However, the locking issue must be fixed!
>
And it is :).

> Holger
>

Thanks,

Johnny
>
>
> _______________________________________________
> GCompris-devel mailing list
> GCompris-devel at kde.org
> https://mail.kde.org/mailman/listinfo/gcompris-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20150827/3220572c/attachment.html>