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.
```
Makes it slightly easier to read+parse what is happening. Yes, for a
Sequence property, the call could apply several changes, but overwhelmingly
it is used to apply a single change.
When switching backends, the effective sample-rate is zero.
This only affects the butler thread (the only active thread when
stopped). The actual issue here is the butler calling
"non-realtime-stop" without a backend. However fixing 0/0
generally seems appropriate.
```
#0 in int_div_round<long>(long, long) (x=0, y=0) at ../libs/pbd/pbd/integer_division.h:36
#1 in Temporal::samples_to_superclock(int64_t, int) (samples=0, sr=0) at ../libs/temporal/temporal/superclock.h:39
#2 in Temporal::timepos_t::timepos_t(long) (this=0x7f94bc0a5890, s=0) at ../libs/temporal/temporal/timeline.h:55
#3 in ARDOUR::Automatable::non_realtime_locate(long) (this=0x55a12a980cc8, now=0) at ../libs/ardour/automatable.cc:421
#4 in ARDOUR::Route::non_realtime_locate(long) (this=0x55a12a980ae0, pos=0) at ../libs/ardour/route.cc:5462
#5 in ARDOUR::Session::non_realtime_stop(bool, int, bool&) (this=0x55a12e0cd000, abort=false, on_entry=1, finished=@0x7f94bc0a5e0f: true) at ../libs/ardour/session_transport.cc:1487
#6 in ARDOUR::Session::butler_transport_work(bool) (this=0x55a12e0cd000, have_process_lock=false) at ../libs/ardour/session_transport.cc:1153
#7 in ARDOUR::Butler::thread_work() (this=0x55a12f3b7000) at ../libs/ardour/butler.cc:222
#8 in ARDOUR::Butler::_thread_work(void*) (arg=0x55a12f3b7000) at ../libs/ardour/butler.cc:16
```
With glib 2.64, volatile gint produce annoying Wcast-qual
compiler warnings with mingw/gcc-8.
Even though the the build succeeds, and only glib 2.68+
requires non-volatile atomics this results in a much
cleaner build-log.
Harvid daemonizes and does not write anything
to stdout/err. as opposed to select(), poll() on
macOS does not return when the child process
terminates or is killed.
However poll() on an invalid FD does throw an
error and POLLNVAL is set.
glib atomic operations include a complete act as a full
compiler and (where appropriate) hardware memory barrier.
std::atomic<> allows dedicated acquire and release barrier
semantics which are not available with glib.
While POSIX defines a single contiguous range of numbers that
determine a thread's priority. Win32 defines priority classes
and priority levels relative to these classes.
pthread maps those to -15 .. +15 with the top six ones
corresponding to REALTIME_PRIORITY_CLASS and max being
THREAD_PRIORITY_TIME_CRITICAL
Note that the PA backend can USE_MMCSS_THREAD_PRIORITIES
and PBD::MMCSS::set_thread_characteristics() directly for
the I/O threads.
Previously the following were treated as equal
"MIDI_foo" == "MIDI bar"
So std::map<> PortManager::_ports and PortEngineSharedImpl:_ports
could only have either. This resulted in missing ports
and missing calls to existing ports in cycle_start().
This mainly affected MIDI tracks with imported files, since there
is "MIDI Clock in", and imported files result in tracks
"MIDI_file-name".
This issue was introduced in 6.6-200-g60ff3ef764
select(2) can only handle file descriptors up to 1024, and there are fairly easy to reproduce
cases where the file descriptor used here is larger than that.
RegionInsertDrag or Consolidate Range or any other operation
calling Playlist::add_region() previously triggered RangesMoved()
which resulted in DiskReader::move_processor_automation()
NB. insert + ripple still moves automation correctly.
strictly speaking the include is not needed here since
g_atomic_compat.h includes glib.h. However it is idempotent,
the file does use glib methods, and g_atomic_compat.h may
one day be removed again.
