Paul Davis
5d023b4c60
The old code assumed that the thread that created a request buffer for a given signal-emitting thread would be the latter thread, and thus a thread-local pointer to the request buffer could be used. This turns out not to be true: the GUI thread tends to be responsible for constructing the request buffers for pre-registered threads. That mechanism has been replaced by using a RWLock protected map using pthread_t as the key and the request buffer as the value. This allows any thread to create and register the request buffers used between any other pair of threads (because the lookup always uses a pthread_t). The symptoms of this problem were a signal emitted in an audioengine thread that was propagated to the target thread, but when the target thread scans its request buffers for requests, it finds nothing (because it didn't know about the request buffer). In a sense, the signal was successfully delivered to the target thread, but no meaningful work (i.e the signal handler) is performed. |
||
|---|---|---|
| doc | ||
| gtk2_ardour | ||
| headless | ||
| libs | ||
| luasession | ||
| msvc_extra_headers | ||
| MSVCardour3 | ||
| MSVCMixbus3 | ||
| MSVCvst_scan | ||
| session_utils | ||
| share | ||
| tools | ||
| .dir-locals.el | ||
| .gitattributes | ||
| .gitignore | ||
| ardour.1 | ||
| COPYING | ||
| nutempo-todo | ||
| PACKAGER_README | ||
| README | ||
| README-GITHUB.txt | ||
| system_config | ||
| TRANSLATORS | ||
| waf | ||
| wscript | ||
Please see the Ardour web site at https://ardour.org/ for all documentation..
For information on building ardour:
https://ardour.org/development.html