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
[email protected]
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
