• jwatzman's avatar
    macosx: call input_changed in extensions · a8ff5278
    jwatzman authored
    This is obnoxiously complicated. If anyone cares about playing_changed or
    meta_changed, something similar will probably have to be done.
    This is a pretty bizarre two-step system to inform the extension manager
    that the input has changed, but it's necessary to avoid a series of
    possible deadlocks and other issues. Here are other possible approaches
    that don't work:
    - Just call into the extension manager in -PlaylistItemChanged on the
    main thread. This can pretty easily cause a deadlock if we call
    -PlaylistItemChanged twice in quick succession. The first call will poke
    the condvar the extension is waiting on, causing the extension thread to
    wake up and run extension code; many parts of it -- including the dialog
    code -- must be run on the main thread. The extension thread goes back to
    sleep while blocking on the main thread to become available, while
    holding the extension lock. Meanwhile the main thread goes into the
    second call of -PlaylistItemChanged, attempts to lock the extension, and
    that's a deadlock.
    - Restructure the dialog manager to never block on the main thread while
    holding the extension lock. This should work, but as it turns out doesn't
    because the main thread will attempt to lock the same lock twice. What
    happens is that -performSelectorOnMainThread works by injecting an event
    into the main event loop of the main thread. For some unknown reason, as
    part of its processing, when creating an NSAttributedString with HTML, it
    runs the main event loop, which means we can end up executing one
    -performSelectoOnMainThread as part of another. Since the dialog manager
    uses attributed strings with HTML (since dialogs are HTML), we deadlock
    here too. This seems strictly like a flaw in NSAttributedString and/or
    in -performSelectorOnMainThread and is documented elsewhere:
    - Change around this bit of code to not force it to run on the main
    thread. This would probably work, but, as a newcomer to VLC, I don't
    quite know the implications of doing this, particularly since a lot of
    code here seems to serailize on the main thread as a way of thread
    safety; it would likely require some somewhat intricate restructuring
    and adding of locks.
    - Let the extension manager deal with listening for events the same way
    that we do here. That would work, but would require duplicating a
    nontrivial amount of code from here to deal with tracking the current
    - So, instead, we just serialized all calls to -PlaylistItemChanged (so
    we make sure to process them in order, with no one trampling
    p_input_changed), do most of the work on the main thread as before, and
    then actually inform the extension manager out here where we don't block
    the main thread. It seems likely that there are other pre-existing
    deadlock possibilities here -- the main thread can't lock an extension!
    -- but it at least tends to work in my testing.
    Signed-off-by: Felix Paul Kühne's avatarFelix Paul Kühne <fkuehne@videolan.org>
intf.h 7.65 KB