Glib mutex performance with uClibc 0.9.28

[jean-marie.verdun at splitted-desktop.org]

Hi Peter,

Don't know if it helps but the osssink version is working with the same 
approach ( clock thread and 3 others ).
It is possible that the cancellation issue is raised during alsasink 
because of the deeper used of threads functions there. (and yes I believe 
it is making call to thread cancellation when it conclude to write to the 
audio device, I need to check if osssink is doing it)
I don't know if you have time to have a look, but that will be great, at 
least to confirm that the issue is coming from what we are suspecting !
Feel free to ask questions if I can be of any help.
Osssink is fine but alsa is much more interesant in term of audio 
playback, especially with the new media player running on top of it and 
the latest gstreamer release (0.10) is more efficient with this default 
sink. 0.8 doesn't raised such issue only because the alsa sink was 
something much more basic by that time.

Jm

On Wed, 12 Jul 2006, Peter S. Mazinger wrote:

> On Wed, 12 Jul 2006 jean-marie.verdun at splitted-desktop.org wrote:
>
>> Hi Peter,
> [...]
>>
>> The "clock" thread is mostly in this state, he is probably the one
>> producing the event to wake up the rendering thread into the poll fd:
>>
>> #0  0xb7bde2bc in __rt_sigsuspend () from /lib/libc.so.0
>> #1  0xb7bde2f3 in sigsuspend () from /lib/libc.so.0
>
> seeing sigsuspend I see already trouble ...
>
> I would have to now if cancellation is happening/tried.
>
> I have made the new linuxthreads working, but using the "old style"
> cancellation, where the non-cancellable version of a function is in
> libc.so, the cancellable one in libpthread.so (old linuxthreads misses
> many of them, sigsuspend in 0.9.28 is not cancellable as well)
> The only function from SuSv3 (supported by uClibc) that I haven't solved
> yet is sigsuspend, for some reason (even if I put a cancellable version
> in libc.so), uClibc does not like it and hangs. Until I don't find a
> solution to have sigsuspend working correctly (pass all tests I have) it
> does even make sense to try the described procedure.
>
> Sorry, Peter
>
> -- 
> Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
> Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2
>