ardour/livetrax
13
0
Fork 0
Code

fix a race condition between the death of a thread that communicates with an UI event loop and the event loop itself.

Browse Source 
The comment tries to explain it all. There may be a better solution, but I believe that this one is
(a) safe (b) better than the old approach.
This commit is contained in:
Paul Davis 2014-03-24 17:47:56 -04:00
parent 012504d35a
commit 87184ab80d
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
libs/pbd/pbd/abstract_ui.cc
View File

@ -44,18 +44,18 @@ cleanup_request_buffer (void* ptr)
{ {
RequestBuffer* rb = (RequestBuffer*) ptr; RequestBuffer* rb = (RequestBuffer*) ptr;
/* there is the question of why we don't simply erase the request /* this is called when the thread for which this request buffer was
* buffer and delete it right here, since we have to take the lock * allocated dies. That could be before or after the end of the UI
* anyway. * event loop that the request buffer communicates.
* *
* as of april 24th 2012, i don't have a good answer to that. * We are not modifying the UI's thread/buffer map, just marking it
* dead. If the UI is currently processing the buffers and misses
* this "dead" signal, it will find it the next time it receives
* a request. If the UI has finished processing requests, then
* we will leak this buffer object.
*/ */
rb->dead = true;
{
Glib::Threads::Mutex::Lock lm (rb->ui.request_buffer_map_lock);
rb->dead = true;
}
} }
template<typename R> template<typename R>