<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi,<br>
<br>
On 08/27/15 21:17, Holger Kaelberer wrote:<br>
</div>
<blockquote cite="mid:55DF622C.9030308@elberer.de" type="cite">Hi
Johnny,
<br>
<br>
On 27.08.2015 10:26, Johnny Jazeix wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
I found a potential deadlock in the DownloadManager.
<br>
<br>
For some activities, we try to load two rcc in a row: for lang
or
<br>
hangman, we need to load words and localized voices.
<br>
<br>
What is actually done is to load the words.rcc and when loaded,
we
<br>
load the voice.
<br>
<br>
Coding speaking, on onStart activity, we call the
registerResource for
<br>
words which locks the rcMutex. Then, as we have connected the
<br>
DownloadManager::resourceRegistered to the
<br>
activity.resourceRegistered, this one calls the Activity.start
which
<br>
tries to load the localized voices which will call the
<br>
registerResource and try to lock the (already locked) rcMutex...
<br>
</blockquote>
<br>
Good catch! This can happen if the signal-slot connections are
DirectConnection-s, which seems to be the case if you experienced
a deadlock.
<br>
<br>
<blockquote type="cite">
<br>
Is there a good practice to avoid that or can we just unlock the
mutex
<br>
before emitting the resourceRegister signal?
<br>
</blockquote>
<br>
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.
<br>
<br>
</blockquote>
<br>
This fixes the issue :). Commit:
<a class="moz-txt-link-freetext" href="https://quickgit.kde.org/?p=gcompris.git&a=commit&h=e0ac0a25a496957d9413d69ad47e52f391df1807">https://quickgit.kde.org/?p=gcompris.git&a=commit&h=e0ac0a25a496957d9413d69ad47e52f391df1807</a><br>
<br>
<blockquote cite="mid:55DF622C.9030308@elberer.de" type="cite">
<blockquote type="cite">
<br>
We could also, load the two rcc in the onStart method and
waiting for
<br>
both rcc to be loaded to start the activity.
<br>
</blockquote>
<br>
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 ... ;-)
<br>
<br>
</blockquote>
<br>
Oops I forgot the link, hangman is still in progress
(<a class="moz-txt-link-freetext" href="https://github.com/clock21am/GCompris-qt/tree/exercise">https://github.com/clock21am/GCompris-qt/tree/exercise</a>).<br>
<br>
<blockquote cite="mid:55DF622C.9030308@elberer.de" type="cite">However,
the locking issue must be fixed!
<br>
<br>
</blockquote>
And it is :).<br>
<br>
<blockquote cite="mid:55DF622C.9030308@elberer.de" type="cite">Holger
<br>
<br>
</blockquote>
<br>
Thanks,<br>
<br>
Johnny<br>
<blockquote cite="mid:55DF622C.9030308@elberer.de" type="cite">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
GCompris-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:GCompris-devel@kde.org">GCompris-devel@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/gcompris-devel">https://mail.kde.org/mailman/listinfo/gcompris-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>