Max Kellermann <[EMAIL PROTECTED]> wrote: > On 2008/09/02 04:10, Eric Wong <[EMAIL PROTECTED]> wrote: > > Max Kellermann <[EMAIL PROTECTED]> wrote: > > > Start exporting the client struct as an opaque struct. For now, pass > > > it only to processCommand() and processListOfCommands(), and provide a > > > function to extract the socket handle. Later, we will propagate the > > > pointer to all command implementations, and of course to > > > client_print() etc. > > > > While I like most of the "client" series, this is one I'm not entirely > > comfortable with. Opaque or not, I've never liked unnecessarily > > exposing structs between unrelated modules. > > > > Instead, we can cache the linear lookup in fdprintf() and client_print() > > for performance. > > To make something handle a command, we have to pass something - your > concept of global variables obviously won't fit here, because there > may be more than one client.
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). > Currently, we pass the file descriptor. That's worse than passing an > opaque struct, since the function makes assumptions on the nature of > the file descriptor. A pointer to an opaque struct is just this - a > pointer, and the function cannot do anything with it except using it > for a well-defined client_XXX() API. Everything, including proper > buffering and delayed writing will be hidden in the implementation. > > 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. -- Eric Wong ------------------------------------------------------------------------- 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
