Robin Gareus 84c51a1411 Fix BaseUI x-thread signal vs thread-start race
Control surfaces c'tor usually subscribe to signals e.g.
PortConnectedOrDisconnected. This happens after the parent BaseUI
is created, but before set_active() -> BaseUI::run() is called.

At this point in time there is no run_loop thread.

There are two options to handle AbstractUI::call_slot():

 A. Queue the event in the event-loop, using the thread-local
    request buffer of the caller. Then hope the BaseUI
    thread is started, and calls ::handle_ui_requests() before
    the memory pool runs out of space.

 B. Handle the event in the calling thread. -- This may not be
    rt-safe and may call functions with locks held by the caller.
    It will however not accumulate events.

This takes approach (B). If _run_loop_thread is NULL, directly
handle the signal.

In the past, prior to 50abcc74b5, approach (A) was taken.
NULL never matched Glib::Threads::Thread::self().

This also reverts a prior attempt (e417495505) to address this issue.
2022-03-02 21:19:12 +01:00
2022-02-03 14:47:24 +01:00
2020-10-18 17:45:32 +02:00
2020-07-06 21:36:12 +02:00
2021-03-23 23:27:45 +01:00

Please see the Ardour web site at https://ardour.org/ for all documentation..

For information on building ardour: 
      
     https://ardour.org/development.html
Description
No description provided
Readme 202 MiB
Languages
C++ 56.5%
C 39.6%
JavaScript 1.3%
Lua 0.9%
Python 0.6%
Other 0.9%