[vlc-devel] commit: Qt: try to avoid a potential race condition (Jean-Baptiste Kempf )

Rémi Denis-Courmont remi at remlab.net
Fri Jan 29 17:38:44 CET 2010


On Fri, 29 Jan 2010 17:15:54 +0100, Jakob Leben <jakob.leben at gmail.com>
wrote:
> On Fri, Jan 29, 2010 at 5:01 PM, Rémi Duraffort <ivoire at videolan.org>
> wrote:
> 
>> >
>> > Was it crashing immediately at startup?
>> As soon as the playlist was opened.
>>
>>
>  Hmmm, I'm afraid this might mean a more serious problem: that all our Qt
> is not protected against thread concurrency! Maybe some of events from
> core don't go to Qt event queue but are handled directly?

VLC core events will almost systematically come from another thread - than
the Qt4 application loop. That typically occurs via VLC object variable
callbacks. Normally, the variable callback (in the VLC Qt4 plugin) is
responsible for ensuring thread-safety. Typically it should:
1/ serialize or reference the callback data, and
2/ post an event to the Qt4 main loop.

So of course, callbacks must emit a signal - they cannot call a slot or a
regular method directly. That ensures thread-safety with regard to the Qt4
main loop. This is relatively easy, although it's also easy to forget.

But this is not sufficient. The callback must ensure that the data it
provides to the Qt4 thread will remain valid. In particular, if it gets a
pointer, the callback must either:
- copy the data (simplest but not always feasible),
- increase the reference of the pointed object,
- not return until after the Qt4 thread has dealt with the request
(dangerous).

We used to have that kind of problems with the error dialogs and with the
embedded video output. But I believe it's fixed. In other word, I am not
aware of a systematic issue with Qt4.

I don't know about the playlist code though.

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis




More information about the vlc-devel mailing list