It can happen that ::get_request() returns NULL if the
EventPool is full. In that case the slot is never called.
In this case the caller can now take action.
We discovered in the past that the C++ API for GSource/Glib::Source has some fatal and unfixable flaws. Copy similar
code and just use the C API for GSource instead
This is based on code from earlier commits that were later reversed, but we need some mechanism
to ensure that threads have a thread local tempo map ptr set. The big difference is that this
time we do not implement this for all instances of an AbstractUI - implementation is left to
each thread/event loop
On M1, the cross-thread channel sets G_IO_PRI in addition to G_IO_IN
this breaks various assumptions in receivers, which test for ~G_IO_IN
as error condition.
Return from poll_for_request() when CrossThreadChannel is
closed/destroyed. -- see also f4166fb61d
This also cleans up poll API usage, and check for nonnegative
return value is added.
This is in preparation for a pure-virtual base class for
PluginInsert to expose `DropReferences` in the virtual base.
```
class PlugInsertBase : virtual public PBD::Destructible
class PluginInsert : public Processor, public PlugInsertBase
class Processor : public SessionObject
class SessionObject : public PBD::StatefulDestructible
```
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.
This is mainly because Glib::Threads (g_system_thread_new)
uses pthread on Un*x, but on Windows relies on GThreadWin32
(HANDLE)_beginthreadex
This later causes issues e.g. in BaseUI::run()
```
unhandled exception (type Glib::Error) in signal handler:
domain: g_thread_error
code : 0
what : Error setting new thread priority: The parameter is incorrect.
```
