Running under valgrind enforces --no-fork so any signal will cause valgrind
to error out, failing the test abnormally. This prevents us from running
our test suite through valgrind, we'd have to mark every test specifically
whether it should run under valgrind or not.
Easier is just to automatically skip tests expecting signals.
This is a bitfield, but it's unclear what it achieves since this is the
only member of a bitfield, so it may be more efficient to just make it a
bool.
Fixes a LGTM warning:
Bit field started of type int should have explicitly unsigned integral, explicitly signed integral, or enumeration type.
This allows to get rid of the empty if block in comparison to
channel_map, and makes it clear that the comparison is useless. So in
the next commit we will remove it.
Fixes an LGTM warning:
Empty block without comment
`sizes` members participate in multiplication and subsequent assignment
into port->bpf, which has size_t. So LGTM rightfully complains, there's
a chance the multiplication will overflow before the assignment happens.
Should have no influence on performance since 64 bit multiplication is
as fast, and since the struct is constified, a wise compiler should make
sure it doesn't take excess space either.
Fixes LGTM warning:
Multiplication result may overflow 'unsigned int' before it is converted to 'size_t'.
That was found by GCC fanalyze pass. Fixes warning:
../spa/plugins/audioconvert/resample-native.c: In function ‘resample_native_init’:
../spa/plugins/audioconvert/resample-native.c:385:9: warning: dereference of NULL ‘0B’ [CWE-476] [-Wanalyzer-null-dereference]
385 | spa_log_debug(r->log, "native %p: q:%d in:%d out:%d n_taps:%d n_phases:%d features:%08x:%08x",
cb6dbd165a made public API incompatible with consumers using
_POSIX_SOURCE, _POSIX_C_SOURCE or _XOPEN_SOURCE: <sys/mount.h>
isn't standalone but depends on BSD-specific types in <sys/types.h>
which are hidden when POSIX compliance is requested.
xdg-desktop-portal-wlr passes -D_POSIX_C_SOURCE=200809L via meson.build
which works for its own code and all other dependencies.
In file included from ../src/core/main.c:7:
In file included from /usr/local/include/pipewire-0.3/pipewire/pipewire.h:35:
In file included from /usr/local/include/pipewire-0.3/pipewire/client.h:35:
In file included from /usr/local/include/pipewire-0.3/pipewire/proxy.h:108:
In file included from /usr/local/include/pipewire-0.3/pipewire/protocol.h:48:
In file included from /usr/local/include/pipewire-0.3/pipewire/utils.h:34:
In file included from /usr/include/sys/mount.h:38:
/usr/include/sys/ucred.h:99:2: error: unknown type name 'u_int'
u_int cr_version; /* structure layout version */
^
In file included from ../src/core/main.c:7:
In file included from /usr/local/include/pipewire-0.3/pipewire/pipewire.h:35:
In file included from /usr/local/include/pipewire-0.3/pipewire/client.h:35:
In file included from /usr/local/include/pipewire-0.3/pipewire/proxy.h:108:
In file included from /usr/local/include/pipewire-0.3/pipewire/protocol.h:48:
In file included from /usr/local/include/pipewire-0.3/pipewire/utils.h:34:
Reported by: Jan Beich <jbeich@FreeBSD.org>
Use the pw_thread_utils interface to create/join and acquire/drop
RT priority. This allows JACK apps to also use the configured module to
handle RT priorities.
Let the module-rt and module-rtkit provide a new pw_thread_utils
implementation.
The pw_thread_utils interface has many advantages over the old way
of boosting the thread:
1. Does not require to add a source to the loop and do priority
boost in-thread.
2. Works on simple threads without data-loop interface.
3. Allows dropping RT priority as well.
The rtkit implementation requires a bit more work because there is
currently no pthread API to map an pthread to a tid. We make a small
wrapper thread to capture the tid with getpid() to do the mapping
ourselves. This should go when the new API arrives. See also:
(https://sourceware.org/bugzilla/show_bug.cgi?id=27880)
Add a function in data-loop to get the natvive thread and use that
in client_thread_id() so that it returns the pthread of the
data thread instead of the caller thread.
200ms seems a little small, some plugins initialize themselves from the
RT thread and get killed. 2 seconds seem to be a better default.
The important part is that there is a limit so that runaway processes
are killed and don't lock up the system.
Fixes#1344
