Re: new patch to help jackd along

> On Fri, May 9, 2008 15:39, Pieter Palmers wrote:
>> Rui Nuno Capela wrote:
>>
>>> On Fri, May 9, 2008 03:24, Paul Davis wrote:
>>>
>>>> Changes:
>>>>
>>>>
>>>> * use poll+read, not just read, when waiting for clients to finish up
>>>>  non-process "event" handling * mark clients as Finished after their
>>>> process callback has executed * remove clients that failed to respond
>>>> to events * add new -r option to completely remove the JACK shm
>>>> registry at startup (orthogonal to everything else, but in my codebase
>>>> for months)
>>>>
>>>> I would commit this directly, but I'm trying to be cautious for once.
>>>> It
>>>> works much better for me now. Note that I believe there may be some
>>>> locking issues still to address in the code (insufficient locking,
>>>> that is, not deadlocks).
>>>>
>>> sorry to tell, but it still fails on the jack_test2.c crash tester (the
>>>  very same at stake on that last night in Cologne:)
>>>
>>> fyi, this is just one simple client that, after a while, enters into an
>>>  endless loop and tests for jackd being able to detect and remove it
>>> from the graph. what happens is that jackd gets severely stuck and
>>> jack_watchdog kicks in and bang! everything is thrown to the floor
>>>
>>> funny thing, and it might just be relevant to the case, is that this
>>> meltdown behavior seems to be most evident when, and only when, the bad
>>>  client shares the graph with any other client. when left alone,
>>> everything seems to work just fine. puzzled ;)
>> For me it seems to be working fine. I'm on a dual core machine though so
>> this might be the reason.
>>
>> I've attached a slightly modified version of your tester that also
>> displays a loop counter for when the process callback enters the stuck
>> loop. for me this gives the following:
>>
>> ppalmers@ox-D820:~/programming/jack/tests$ ./jack_test2 2> log
>> seconds to run: 30 num.of ports: 2 client_name: jack_test2-32116
>> jack_test2-32116: client_new
>> jack_test2-32116: port_register
>> jack_test2-32116: set_process_callback
>> jack_test2-32116: on_shutdown
>> jack_test2-32116: activate
>> jack_test2-32116: connect: jack_test2-32116:out_0 -> system:playback_1
>> jack_test2-32116: connect: jack_test2-32116:out_1 -> system:playback_2
>> jack_test2-32116: running(0, 0)...  1
>> jack_test2-32116: mark!
>> jack_test2-32116: running(1, 2071971914)... 54
>> *** shutdown ***
>> jack_test2-32116: running(1, 2147483647)... 48
>> ppalmers@ox-D820:~/programming/jack/tests$
>>
>>
>> after the shutdown message, the counter stops increasing, so the process
>> callback is dead. The client itself stays alive, as I would expect it to
>> be. This is both with and without other clients in the graph.
>>
>
> did you test it also when some other (sane) client is in the graph? eg.
> qjackctl active?
>
> i do get a similar (good) behavior when jack_test2 is the *single* client
> around, having either jackd patched or not. big problem seems to occur
> when jack_test2 is *not* the first client in the graph