Denis Oliver Kropp wrote: > 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'.
There are at least two issues with taking the lock again on error: - if a timeout is used which expires, waiting to regain the lock can take much longer - if a signal is received, I'm not sure, but I think we must/should not wait at all (zombie) The first one should also be a problem with mutex/condition and is enough for me to think that not taking the lock again on error makes more sense. The second one might be solvable. The user space library repeats the ioctl as long as EINTR is returned. Actually, this should cause an EIO with the current code, because waiting without a lock is not allowed. So when the ioctl is called it needs to figure out if the previous call was interrupted and at which point... -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
