On 20/08/20 14:00, Christian Schoenebeck wrote:
> One way would be a recursive type and logging a warning, which you obviously
> don't like; another option would be an assertion fault instead to make
> developers immediately aware about the double lock on early testing. Because
> on a large scal
On 21/08/20 13:28, Geoffrey McRae wrote:
>
>> My suggestion is to work towards protecting the audio code with its own
>> mutex(es) and ignore the existence of the BQL for subsystems that can do
>> so (audio is a prime candidate). Also please add comments to
>> audio_int.h about which functions ar
My suggestion is to work towards protecting the audio code with its own
mutex(es) and ignore the existence of the BQL for subsystems that can
do
so (audio is a prime candidate). Also please add comments to
audio_int.h about which functions are called from other threads than
the
QEMU main t
On Donnerstag, 20. August 2020 12:54:49 CEST Paolo Bonzini wrote:
> More on the practical side, recursive mutex are an easy way to get a
> deadlock. It's a common idiom to do
>
> /* Need to take foo->lock outside bar->lock. */
> mutex_unlock(&bar->lock);
> mutex_lock(&foo->lock);
>
On 20/08/20 12:06, Christian Schoenebeck wrote:
> Hmmm, as Geoffrey already added a lock today, I noticed that QEMU's main IO
> thread mutex is not initialized as 'recursive' lock type. Does that make
> sense? I.e. shouldn't there be a
>
> qemu_rec_mutex_init(&qemu_global_mutex);
>
> in s
On Donnerstag, 20. August 2020 07:37:28 CEST Gerd Hoffmann wrote:
> Hi,
>
> > > +qemu_bh_cancel(c->shutdown_bh);
> >
> > Looks like a potential race. Quote from the API doc of qemu_bh_cancel():
> > "While cancellation itself is also wait-free and thread-safe, it can of
> > course ra
Hi,
> > +qemu_bh_cancel(c->shutdown_bh);
>
> Looks like a potential race. Quote from the API doc of qemu_bh_cancel():
>
> "While cancellation itself is also wait-free and thread-safe, it can of
>
> course race with the loop that executes bottom halves unless you are
On 2020-08-20 01:21, Christian Schoenebeck wrote:
On Mittwoch, 19. August 2020 08:29:39 CEST Geoffrey McRae wrote:
This change registers a bottom handler to close the JACK client
connection when a server shutdown signal is recieved. Without this
libjack2 attempts to "clean up" old clients and
On Mittwoch, 19. August 2020 08:29:39 CEST Geoffrey McRae wrote:
> This change registers a bottom handler to close the JACK client
> connection when a server shutdown signal is recieved. Without this
> libjack2 attempts to "clean up" old clients and causes a use after free
> segfault.
>
> Signed-o
This change registers a bottom handler to close the JACK client
connection when a server shutdown signal is recieved. Without this
libjack2 attempts to "clean up" old clients and causes a use after free
segfault.
Signed-off-by: Geoffrey McRae
---
audio/jackaudio.c | 29 --
10 matches
Mail list logo
