25.01.2013 2:38, Denis Krjuchkov пишет: > > Any ideas would be appreciated. >
Here is my idea. I've done some code reading. Looks like the problem in the SocketMonitor/MultiSocketMonitor implementation. In the line 98 in SocketMonitor.cxx GPollFD is initialized directly: > poll = {fd, 0, 0}; This is not supported on Windows port of GLib: http://developer.gnome.org/glib/2.31/glib-The-Main-Event-Loop.html#GPollFD > gint64 fd; > the file descriptor to poll (or a HANDLE on Win32) http://developer.gnome.org/glib/2.31/glib-The-Main-Event-Loop.html#g-poll > If you need to use g_poll() in code that has to run on Windows, the > easiest solution is to construct all of your GPollFDs with > g_io_channel_win32_make_pollfd(). This "informative" commentary actually hides important implementation detail: For various reasons GLib does not use select() directly. It uses WSAEventSelect() to associate an event object with particular socket. g_poll() uses WaitForMultipleObject() to poll them. This probably could be fixed by copy-pasting some code from GLib which seems bad idea because GLib would be eventually removed. Basing on what I've seen in the code MPD's event library seems close enough to drop GLib event-loop. Any other event-loop implementation will likely not suffer from such API differences. So once other event-library is used this problem would be resolved. -- Denis ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team