Max Kellermann <[EMAIL PROTECTED]> wrote:
> On 2008/09/06 08:25, Eric Wong <[EMAIL PROTECTED]> wrote:
> > 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...
>
> Sorry, I was mistaken here - looking at fdprintf() again, I feel a
> strong dislike for this whole function, because it tries to "detect"
> stdout and stderr as a special case. If code wants to interact with
> the client according to the MPD protocol spec, it should use
> client_xyz(), and if it wants to log something, it should use LOG().
And database_printf(), state_file_printf(), playlist_printf()?
No thanks.
One of the things UNIX really got right is that the read()/write()
syscalls are very flexible. The whole operating system is based around
(most) everything being a file. It is an absolutely beautiful idea, so
naturally mpd draws from it.
Of course, we shouldn't emulate the missteps, either:
fcntl/ioctl/{set,get}sockopt
select/poll not working everywhere
open vs socket+connect
...
--
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
