On 2008/09/06 05:51, Eric Wong <[EMAIL PROTECTED]> wrote: > mpd serializes client commands and only handles one client at a time > sequentially. This has always been the case and won't change. > > The only times serializing the interface/client is problematic is > because we wait on the decoder to start up (mainly because of blocking > open(2)). This will be fixed when the InputStream layer is overhauled > (hopefully this weekend).
This is problematic with _every_ command which can block. Which is basically every command, because the main thread waits for the player and the decoder thread after every command. I have already thought about making the main thread fully asynchronous and always consistent. > > Why implement lookup algorithms for fd->pointer, when you can use the > > pointer in the first place? > > We go through the trouble of passing only file descriptors to other > layers because we can reuse generic printing/formatting code for both > writing to files (playlists/database/state) and to clients. No, no, that is bad misuse. fdprintf() is synchronous I/O, and it circumvents the buffering in the client struct. Plus, as I said, the code shouldn't know anything about the nature of this file descriptor. Everything should be managed deep inside client.c. I have already provided client_printf() in my patch set. 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
