On 2008/10/01 12:36, Eric Wong <[EMAIL PROTECTED]> wrote: > But you wouldn't know if a notify_signal() even succeeded in > delivering a signal or not (I haven't fully read the rest of the > output rewrite).
If nobody is waiting currently, the "pending" flag is set. If somebody is waiting, he gets the signal. In the first case, the caller might want to wait for the other thread to really receive the signal, but most of the time, he's not interested in when the other thread receives the signal, but when it's finished the command. > And the eventual response could be a wakeup from much earlier > notify_signal() call, couldn't it? Maybe, then it would check if there's work to do, see that there is nothing, and call notify_wait() again. That's a few wasted CPU cycles in some corner cases which we should just aim to reduce. > Perhaps notify_signal() should return EBUSY if pending is already > set? All callers I know of don't care. As soon as somebody starts to care, we could add that. But then again, this behaviour would be racy, since during notify_signal() returning, the pending flag could be reset.. > Adding a user-configurable async flag to each audio_output > (defaulting to off for backwards compatibility) for playback could > be useful. This way users can choose which outputs they value over > others. There could be a "primary" output - the first one which is configured? > enable/disable/close/open should always be async, though; just > playback should be (optionally) synchronous. Why? open() is my favorite method which might block the full MPD daemon if that isn't performed asynchronously. > synchronous notification is much easier in some cases. It is much > nicer for some "fast" things such as dropping the output buffer when > skipping tracks; but I agree that async is much better in many > cases, too... But with my code, all N output devices can drop their output buffer at the same time. That may require some long lasting blocking system calls. > I would just use pthread_mutex_trylock() and then broadcast if I get > locks from the required set of outputs... Too complicated, for no good reason. > No races, but one bug and the aforementioned issue: > > A definite bug: pthread_cond_wait is subject to spurious wakeups so you > need to restart pthread_cond_wait if pending is not set. > assert(notify->pending) is wrong after pthread_cond_wait. It is? That's not documented... well, to be on the safe side, I have added a patch for that. Max ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
