It's using a compat version on Windows/Android/OS2 which is not available
to external modules.
This new header can't be used directly from external modules on Windows.
This makes vlc_threads.h usable from external modules on Windows.
include/vlc_threads.h:434: warning: The following parameter of vlc_sem_init(vlc_sem_t *sem, unsigned count) is not documented:
parameter 'sem'
include/vlc_threads.h:515: warning: The following parameter of vlc_latch_count_down(vlc_latch_t *latch, size_t n) is not documented:
parameter 'latch'
include/vlc_threads.h:531: warning: The following parameter of vlc_latch_count_down_and_wait(vlc_latch_t *latch, size_t n) is not documented:
parameter 'latch'
include/vlc_threads.h:508: warning: The following parameter of vlc_latch_init(vlc_latch_t *latch, size_t value) is not documented:
parameter 'latch'
The semantics and names mimick the C/C++2X latch. Latches are a
generalisation of barriers, whence counting down and waiting are
(or rather, can be) done separately.
Note that the C2X uses ptrdiff_t but with does not define negative
values. This uses size_t instead, not squandering the sign bit.
The warning was always triggered because __builtin_constant_p actually
checks whether the tested value is constant at compile time and strlen()
was never constant at compile time.
Note that __builtin_constant_p can be used with a non-constant test
expression while using the same expression after ? in a ternary
condition.
It exists in very old gcc and clang.
VLC_WARN_CALL/VLC_ERROR_CALL may not warn though.
Don't define check_delay/check_deadline otherwise and don't force the
vlc_tick_sleep/vlc_tick_wait calls.
Given the amount of threads used by VLC it can be useful to known which thread
is what when debugging or in a backtrace (especially if the stack is bogus, we
can get a hint at where the thread comes from).
This feature is supported in the Windows debugger when used on Windows 10 1607
and upper. There might be support in gdb on other platforms as well.
The posix variants comes from dav1d.
It is not used in POSIX systems. On other system it probably don't make a
difference anymore, only Windows has actual useful values for
VLC_THREAD_PRIORITY_XXX. The synchronization is more important than having some
threads called more often than others.
As briefly noted in 0a8a53335b, that
changeset removed the confusing and messy limitations of mutex
assertions. Previously, it would only work if:
- checking for hold, not for non-hold,
- POSIX threads was used,
- LibVLC was built in debug mode,
- the mutex was initialised dynamically (not `VLC_STATIC_MUTEX`).
The support for detached threads has been removed completely. There is
no need to document then in vlc_join now.
See the following commits:
android: thread: remove unused detached thread support
043d7ebf6b
os2: thread: remove unused detached thread support
f09937dc6d
win32: thread: remove unused detached thread support
8675f083e7
threads: remove vlc_clone_detach()
a10ac09d42
Deprecate vlc_clone_detach()
c5f960ff25
So we tell the thread was canceled. NULL is usually the value returned by
threads terminating normally.
The proper value to return on a canceled thread is VLC_THREAD_CANCELED.
So we tell the thread was canceled. NULL is usually the value returned by
threads terminating normally.
The proper value to return on a canceled thread is VLC_THREAD_CANCELED.
These functions are functionally at the intersection of threading and
atomic operations. But then again, atomic operations in general are
intrinsically dependent on threading.
On the practical side, <vlc_atomic.h> is not an implicit header in
<vlc_common.h>, unlike <vlc_threads.h>. So this change actually lessens
the namespace "pollution".
This provides a common implementation of fast (non-debug),
error-checking (debug) and recursive muteces on top of
vlc_atomic_wait() and vlc_atomic_notify_one(), using Drepper's tristate
mutex algorithm.
Benefits of this implementation include:
- Error checking is supported on all platforms (including Windows).
- Initialization can never fail, is not subject to aborts.
- Destruction is a no-op and can be removed altogether.
- Static muteces do not leak or need kludges.
- Ownership can be checked directly without the mutex mark system.
- Non-ownership can be checked in assertion.
Because the player code uses the same vlc_mutex_t typedef for both
non-recursive and recursive usages, disentanglement is not possible.
This patchset thus supports both semantics together as before.
Steve Lhomme
Alexandre Janniaux
Denis Charmet
Rémi Denis-Courmont
KO Myung-Hun
Marvin Scholz