2013/5/22 RJ Ryan <notifications@github.com>

> In mixxx/src/playermanager.cpp:
>
> > @@ -46,6 +50,17 @@
> >              this, SLOT(slotNumPreviewDecksControlChanged(double)),
> >              Qt::DirectConnection);
> >
> > +    // Make sure the number of internal decks is in sync with the number of decks in the skin.
> > +    connect(m_pCOSkinNumDecks, SIGNAL(valueChanged(double)),
> > +            this, SLOT(slotNumDecksControlChanged(double)),
> > +            Qt::DirectConnection);
>
> Oops, GitHub did a really bad job formatting my reply-via-email.
> Re-posting:
>
> That's not true -- an AutoConnection decides between direct invocation and
> queueing based on the emitting thread and the receiver object's thread
> property alone (if they match, direct. if not, queue). Nothing we did in
> atomic-co changes this -- a non main thread change made to this control (by
> looking it up with getControl or in the case of our many shared state
> multiple thread classes) would queue, not directly invoke. Also queueing is
> not acceptable here because other parts of Mixxx want this processing to be
> done immediately (eg so skin processing doesn't have to block while waiting
> for PlayerManager to get the signal) and this class is designed to be
> thread safe (locks) because of this.ect
>
Hi RJ,

in general, you are right, but in this case we have a double signal, one
with (QObject* sender), which is a queued connection in case of a different
sender and a direct connection else. The final signal without sender is a
direct connection in any case. But isn't the PlayerManager and the
LegacySkin parser in the same thread anyway?


> —
>
> Reply to this email directly or view it on GitHub<https://github.com/mixxxdj/mixxx/pull/6/files#r4343623>
> .
>
>