Max Kellermann <[EMAIL PROTECTED]> wrote: > On 2008/09/06 05:51, Eric Wong <[EMAIL PROTECTED]> wrote: > > > 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.
Huh? fdprintf() is not synchronous I/O to sockets; never has been (it was formerly myfprintf and used stdio FILE *, but even then it was async). I haven't looked too closely at your changes to client, but it definitely does not circumvent buffering in any other version of mpd. fdprintf calls interfacePrintWithFD; which has always done buffering since 2003... -- 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
