Old-style TLS keys only need to be in the list if they have a
per-thread destructor. If they don't, then don't put them in that list,
so iterating the list is faster.
Old-style TLS keys only need to be in the list if they have a
per-thread destructor. If they don't, then don't put them in that list,
so iterating the list is faster.
* Do not share the notification object for two different events.
* Use binary semaphores instead of boolean and condition variables.
* Use an relaxed atomic variable, get rid of unnecessary lock.
In normal cases, the preparse status would not need to be an atomic
variable, as the preparse semaphore serves as proper barrier. However
in the abort case, the status is written by the "wrong" thread.
Still, we can rely on the semaphore to provide a synchronisation
barrier on the status value.
We won't be limited to 32 futeces on platforms that have the API.
The DLL to use is api-ms-win-core-synch-l1-2-0.dll [1].
It could also be in api-ms-win-core-synch-l1-2-1.dll [2].
Maybe it existed as some point in kernel32.dll but it doesn't on my Win10.
Mingw64 has this comment:
; MSDN says it's in Kernel32.dll but it's not.
; Link with libsynchronization.a instead.
; Commented out for compatibility with older
; versions of Windows.
;WaitOnAddress
;WakeByAddressSingle
;WakeByAddressAll
It seems we can use GetModuleHandle() as the DLL is implied by loading kernel32.
This will avoid calling FreeLibrary from DllMain.
In case it doesn't work we fallback to the local implementation of futex.
[1] https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitonaddress
[2] https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-synch-l1-2-0dll
Slim Reader/Write locks [1] are lighter than critical sections.
They don't require a release and even provide a static initializer.
We only use the exclusive mode which forbids recursive calls within a thread.
Only available since Vista so cannot be backported to 3.0.
[1] https://docs.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--srw--locks
VSYNC skipping is used when a picture has been rendered too late and
used the VSYNC coming afterwards, meaning that the next VSYNC cannot be
used. Skipping ensures that prepare/display happens right after the
previous VSYNC, shifting it as much as possible from the VSYNC it's
rendering for.
When using timestamp vs targetTimestamp, one must take care to compare
the VSYNC against the previous VSYNC (so targetTimestamp vs previous
targetTimestamp) and not use timestamp + targetTimestamp.
Also get the current time through CoreAnimation time functions to build
the difference with now, allowing a bit of latency to be introduced in
timestamp.
There is currently two state in the state machine:
- handling controls
- displaying a picture
This helps refactoring the whole handling of termination, and later
introduce interruption more easily as a state transition.
The dropping message makes no sense when the picture has already been
rendered, since it can happen when VSYNC is actively resampling at the
same frequency, but with enough latency to not be late on the pictures.
Release configuration is used to build the frameworks for the final
application, including full bitcode support, so it needs to be enabled
there.
xcodebuild \
-scheme AVPipelineImpl \
-configuration Release \
-alltargets clean \
-derivedDataPath ./build build
Rémi Denis-Courmont
Romain Vimont
Francois Cartegnie
Steve Lhomme
Alexandre Janniaux
Thomas Guillem