On Sun, 01.03.09 02:27, Colin Guthrie (gmane at colin.guthr.ie) wrote: > Hi, > > I was trying to debug a deadlock while using gvim (with > libcanberra+pulse output: https://qa.mandriva.com/show_bug.cgi?id=44925) > I had reason to read the threaded loop docs. > > The reference implementation shown here: > http://0pointer.de/lennart/projects/pulseaudio/doxygen/threaded_mainloop.html#basic_subsec > > In my mind, the operation could theoretically be cancelled and this the > _get_state() will return PA_OPERATION_CANCELLED. > > In the example code, if this happens, the loop will spin and the main > loop will never be unlocked. > > This could be fixed by spinning when the state is PA_OPERATION_RUNNING > rather when it is not PA_OPERATION_DONE (incidentally, there is a typo > in the docs... it says OPERATION_RUNNING without the PA_ prefix...). > > Anyway, any comments on this observation would be appreciated. PA_OPERATION_CANCELLED is a state that is only entered after the *client* called pa_operation_cancel(), i.e. it needs to be triggered from the same code that waits for pa_operation_get_state() becoming PA_OPERATION_DONE. Hence waiting for _DONE is actually safe. That said it is probably still more robust if we'd only loop as long as _RUNNING is the current state so that this loop properly exits should the client code be eventullay changed to call _cancel somewhere. I have now changed this in my local git tree here. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4
