Claudio Ciccani wrote: > Il giorno sab, 16/02/2008 alle 05.53 +0100, [EMAIL PROTECTED] ha scritto: >> New commits: >> >> http://git.directfb.org/?p=core/FusionSound.git;a=commit;h=3bf19d0ace5ddc385c3137e4fac6566ff4ef402f >> commit 3bf19d0ace5ddc385c3137e4fac6566ff4ef402f >> Author: Denis Oliver Kropp <[EMAIL PROTECTED]> >> Date: Tue Jan 22 00:06:32 2008 +0100 >> >> Don't dismiss the skirmish if fusion_skirmish_wait() fails. >> >> Only when DFB_OK is returned, the lock is still held. >> >> src/core/core_sound.c | 4 +--- >> 1 files changed, 1 insertions(+), 3 deletions(-) >> > > Just want to point out that this change will be causing a deadlock when > using the single or the builtin implementation of fusion. > Indeed the behaviour of fusion_skirmish_wait() in linux-fusion is > incompatible with the one defined by pthread_cond_timedlock(); i.e. > pthread_cond_timedwait() always reacquires the mutex before returning, > either when timeout occurred.
Yes, I thought about the incompatibility, but not the dead lock. Let's see if it can be changed in linux-fusion, though I think my logic makes more sense, if it timeouts or gets an error, in both cases not the desired event, why lock the object again? But in this case I'd better go with the flow, and wait 'inside'. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-cvs mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-cvs
