Version: (using KDE 4.0.0) I have seen that no loop is used around the call of the function "pthread_cond_wait" in the function "cdda_fct_play". http://websvn.kde.org/trunk/KDE/kdemultimedia/libkcompactdisc/wmlib/cdda.c?revision=756952&view=markup Would you like to reuse anything from my message on the topic "spurious wakeup"? http://groups.google.de/group/comp.programming.threads/msg/bb8299804652fdd7 I have got doubts about your handling of condition variables. http://en.wikipedia.org/wiki/Monitor_%28synchronization%29#Condition_variables
Hi, I would like to make clear... man pthread_cond_wait The pthread_cond_timedwait() and pthread_cond_wait() functions may fail if: EINVAL The value specified by cond, mutex, or abstime is invalid. EINVAL Different mutexes were supplied for concurrent pthread_cond_timedwait() or pthread_cond_wait() operations on the same condition variable. EPERM The mutex was not owned by the current thread at the time of the call. These functions shall not return an error code of [EINTR]. !!! Also it's not allowed for pthread to return if wakeup is occurs. !!!
> Also it's not allowed for pthread to return if wakeup is occurs. Your expectation is wrong for the POSIX interface. http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_wait.html "Spurious wakeups from the pthread_cond_timedwait() or pthread_cond_wait() functions may occur."
I recommend to add a loop for the predicate check. When will the implementation of the function "cdda_fct_play" be completed together with error detection and corresponding exception handling? http://websvn.kde.org/trunk/KDE/kdemultimedia/libkcompactdisc/wmlib/cdda.c?revision=826360&view=markup
Hi, feel free to propose a patch. Greetings Alex
I have got the impression that it might be hard to achieve consensus on an acceptable patch in the combination with proper error handling. I would also need a clarification for the predicate that should be waited for in a loop.
Markus, it seems to me that the "wakeup" local variable in cdda_fct_read() is the predicate you would need. Of course the variable would have to be moved to a more shared namespace (wm_drive?) to make that work.
Your suggestion is not clear for me because I do not see so far how a useful wait condition would be derived from the input parameter "arg/wm_drive". Which predicate would be meaningful? By the way: I wonder why the global variable "blks_mutex" is not initialised in this source file. I would expect calls to the function "pthread_mutex_init" for each array element.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
(In reply to Andrew Crouthamel from comment #8) It find that the implementation of the function “cdda_fct_play” will need further adjustments (if the affected software library is still relevant today). https://github.com/KDE/libkcompactdisc/blob/4a465e259a62ebd6b1c4993e5821968777aeda6d/src/wmlib/cdda.c#L287
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
(In reply to Justin Zobel from comment #10) Would you like to help any more with a proper source code review? https://github.com/KDE/libkcompactdisc/blob/1771e180811d8a3f87f3e1a0003ab0360564c021/src/wmlib/cdda.c#L287