Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 11:06, Denis Krjuchkov de...@crazydev.net wrote: As I've saw in git MPD is still going to use GLib's mutex/condvar implementations for Windows. Actually, I'd love to use std::mutex et al, but that's not available on the mingw-w64 version shipped in Debian. I could try a newer version, but my goal is to make it buildable with Debian tools. However the Linux port of MPD doesn't use std::mutex because it (the GNU libstdc++ implementation) adds overhead. The lock() method needlessy checks the return value and throws an exception on error, even when exceptions are disabled. Very small overhead, but still unnecessary. May be we could just take pthreads-win32 instead? http://sourceware.org/pthreads-win32/ That would be another dependency, wouldn't it? Yes, we could do that. My rationale for removing GLib was to make porting to Android possible, and therefore GLib will be removed from the normal Linux build first. Removing it from Windows is not my goal, but pthread-win32 sure could help with that. Another idea I had was use the native WIN32 condition variables, which requires Windows Vista or newer. I'm not sure if that's a problem. I mean, Windows XP is 13 years old and its support will finally expire in just a few months. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682052.aspx This will be less overhead than pthreads-win32, because it doesn't attempt to emulate a foreign API. (Next problem is that the prototypes for this API are not available in Debian's mingw-w64 *sigh*) Max -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
10.01.2013 16:19, Max Kellermann пишет: That would be another dependency, wouldn't it? Yes, we could do that. You're right. This is another dependency. But it's easy to build it (no transitive dependencies). Also it simplifies code because other platforms use pthreads too (if I'm understanding right). It does not require newer toolchain as well. My rationale for removing GLib was to make porting to Android possible, and therefore GLib will be removed from the normal Linux build first. Removing it from Windows is not my goal, but pthread-win32 sure could help with that. So practically using GLib API is a transitional solution. I have no objections against that. Another idea I had was use the native WIN32 condition variables, which requires Windows Vista or newer. I'm not sure if that's a problem. I mean, Windows XP is 13 years old and its support will finally expire in just a few months. This might be a good idea since Vista provides other useful APIs. Such as poll() implementation: http://msdn.microsoft.com/en-us/library/ms741669%28v=vs.85%29.aspx This will be less overhead than pthreads-win32, because it doesn't attempt to emulate a foreign API. (Next problem is that the prototypes for this API are not available in Debian's mingw-w64 *sigh*) May be newer Debian would be available in the meanwhile before the first 0.18 stable release? I use Kubuntu 12.04. It has condvar API available in mingw-w64. -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 11:43, Denis Krjuchkov de...@crazydev.net wrote: This might be a good idea since Vista provides other useful APIs. I don't care much about Windows. For many years, I was careful about requiring Vista+, because I thought many users were still happy with XP, and I did not want to force anybody to buy a new OS version. But I guess the times of XP are over. Requiring Vista+ is ok for me if nobody else objects. Such as poll() implementation: http://msdn.microsoft.com/en-us/library/ms741669%28v=vs.85%29.aspx I'm not yet sure if we will need this. The next big step is eliminating the GLib event loop. I wouldn't like to reimplement this from scratch, rather use libevent (which I have been using a lot in other projects), but I'm not sure how portable libevent really is. I use Kubuntu 12.04. It has condvar API available in mingw-w64. Which mingw32-runtime version is that? I have 3.13-1, and it does not provide CONDITION_VARIABLE. -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 11:52, Max Kellermann m...@duempel.org wrote: Which mingw32-runtime version is that? I have 3.13-1, and it does not provide CONDITION_VARIABLE. Oh, I was looking at the wrong directory. Should be mingw-w64-i686-dev, and indeed CONDITION_VARIABLE can be found there. -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
10.01.2013 16:52, Max Kellermann пишет: I'm not yet sure if we will need this. The next big step is eliminating the GLib event loop. I wouldn't like to reimplement this from scratch, rather use libevent (which I have been using a lot in other projects), but I'm not sure how portable libevent really is. There is libev also (not sure which one is better). One thing I really dislike in current event loop is how event_pipe (or GlobalEvents in master) works on Windows. Windows does not support select()/poll()/etc on pipes. GLib emulates polling using separate reader/writer thread. This is a significant overhead IMO considering what event_pipe is used for. The most straightforward implementation is to use Win32 events. However this requires an event loop that does polling using WaitForMultipleObjects() function instead of select(). Likely this is not possible with libevent/libev but needs checking. Probably separate socket pair could be used instead of pipe. This would at least eliminate extra-thread. -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 12:13, Denis Krjuchkov de...@crazydev.net wrote: Probably separate socket pair could be used instead of pipe. This would at least eliminate extra-thread. Why not. Good luck I factored out that code into the class WakeFD (for adding Linux's eventfd()). We can now easily exchange the pipe() call with socketpair() on WIN32. -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
10.01.2013 17:20, Max Kellermann пишет: Why not. Good luck I factored out that code into the class WakeFD (for adding Linux's eventfd()). We can now easily exchange the pipe() call with socketpair() on WIN32. I could try that. But unfortunately master does not build for me. OpusReader.hxx uses strndup() which is not available in mingw-w64. Was it meant to be g_strndup()? mingw lacks strndup() at the moment. -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 12:24, Denis Krjuchkov de...@crazydev.net wrote: Last time I saw it MPD used int type for sockets. Windows API actually defines a SOCKET type which a typedef for UINT_PTR. WTF? From my observations socket handles grow sequentially from small numbers to higher. This makes error unnoticeable. What is the practical problem then? After MPD has accepted its two billionths client, further connects will fail? I could try to provide a patch for mpd/mpc/libmpdclient but not sure what's the best way to do it. Define separate type (i.e. mpd_socket) that always is a typedef for correct socket type. Or just #ifdef in each particular usage? In MPD, there should be a class wrapping a socket descriptor, which hides implementation specific details. Also this might break the API of libmpdclient and I'd like to avoid API breaks for other platforms. On Linux, we could easily use symbol versions, but on Linux this isn't a problem anyway. I don't know if DLLs can have versioned symbols. But on Windows, we could add another symbol for the SOCKET type, and make all functions with int static+inline wrappers which cast to SOCKET and call the new function. Therefore, binaries which were compiled with the new headers will use the new symbols, and old binaries will continue to use the old symbols (which will continue to exist as long as 2 is the major version). -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 12:32, Denis Krjuchkov de...@crazydev.net wrote: Was it meant to be g_strndup()? mingw lacks strndup() at the moment. Actually, I wanted to avoid using GLib in new code. Since strndup() is a standard API, not a GNU extension, I presumed it was safe to use.. -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
10.01.2013 17:20, Max Kellermann пишет: Why not. Good luck I factored out that code into the class WakeFD (for adding Linux's eventfd()). We can now easily exchange the pipe() call with socketpair() on WIN32. Just looked at libevent documentation. http://www.wangafu.net/~nickm/libevent-book/Ref4_event.html It seems that it supports user events which makes event_pipe implementation on top of it easy. So there would be no problem here. -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
10.01.2013 17:36, Max Kellermann пишет: Actually, I wanted to avoid using GLib in new code. Since strndup() is a standard API, not a GNU extension, I presumed it was safe to use.. According to this http://linux.die.net/man/3/strndup strndup() is defined in POSIX.1-2008. Likely mingw-w64 does not support such recent standard. -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
10.01.2013 17:34, Max Kellermann пишет: WTF? It's called Windows programming :-D You could inspect psdk_inc/_socket_types.h What is the practical problem then? After MPD has accepted its two billionths client, further connects will fail? I'm not sure if this is documented behavior or rather implementation detail. Just my observations on my particular system. Since nobody complained about such errors it looks that such situation is a current behavior for many systems. In MPD, there should be a class wrapping a socket descriptor, which hides implementation specific details. That's simplest part On Linux, we could easily use symbol versions, but on Linux this isn't a problem anyway. I don't know if DLLs can have versioned symbols. But on Windows, we could add another symbol for the SOCKET type, and make all functions with int static+inline wrappers which cast to SOCKET and call the new function. Therefore, binaries which were compiled with the new headers will use the new symbols, and old binaries will continue to use the old symbols (which will continue to exist as long as 2 is the major version). So practically this requires adding one more function for each function that deal with sockets? If new functions would be implemented as static+inline wouldn't it break the ABI for already compiled programs? Because such functions exist only at compilation stage and are not present in the compiled .DLL -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 13:06, Denis Krjuchkov de...@crazydev.net wrote: So practically this requires adding one more function for each function that deal with sockets? Yes. That's three: mpd_async_new(), mpd_async_get_fd() and mpd_connection_get_fd(). If new functions would be implemented as static+inline wouldn't it break the ABI for already compiled programs? Because such functions exist only at compilation stage and are not present in the compiled .DLL True, this is where it gets hairy. There must be three versions of mpd_async_new(): - the new symbol mpd_async_new_SOCKET with SOCKET parameter (shall never be explicitly called by applications, part of the ABI but not the API) - the inline function mpd_async_new with SOCKET which calls mpd_async_new_SOCKET (this being the only caller of mpd_async_new_SOCKET) - the old symbol mpd_async_new with int which also calls mpd_async_new_SOCKET (after casting to SOCKET) - to satisfy the old ABI -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
10.01.2013 18:17, Max Kellermann пишет: If new functions would be implemented as static+inline wouldn't it break the ABI for already compiled programs? Because such functions exist only at compilation stage and are not present in the compiled .DLL True, this is where it gets hairy. There must be three versions of mpd_async_new(): - the new symbol mpd_async_new_SOCKET with SOCKET parameter (shall never be explicitly called by applications, part of the ABI but not the API) - the inline function mpd_async_new with SOCKET which calls mpd_async_new_SOCKET (this being the only caller of mpd_async_new_SOCKET) - the old symbol mpd_async_new with int which also calls mpd_async_new_SOCKET (after casting to SOCKET) - to satisfy the old ABI Good, this would require some preprocessor hardcore but looks doable. GLib sources seem to have lots of such hacks I'll consider them as an example. Could the suffix be something like _win32_socket instead of _SOCKET which is ugly and anyway does not clarify what it's for? -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 13:24, Denis Krjuchkov de...@crazydev.net wrote: Could the suffix be something like _win32_socket instead of _SOCKET which is ugly and anyway does not clarify what it's for? Yes. That was just a quick example. This is truly crap, and I'm not even sure this is worth fixing. If there are practical problems with int/SOCKET, I wonder if making it libmpdclient2b.dll would be a better solution. -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 13:32, Denis Krjuchkov de...@crazydev.net wrote: GLib uses different approach as you know. They provide separate APIs for dealing with sockets for Unix and Windows. This requires user to write several #ifdef's but makes things clear. Couldn't we consider similar approach? This looks like the worst possible solution. Sure, it reduces the complexity of a possible libmpdclient solution, but that complexity has not disappeared - it is just being moved (and multiplied) to every single application. And it doesn't even have much to do with our current problem. Our problem is that we didn't use the proper data type for sockets on WIN32, and we can't fix this without modifying the ABI. Diverting the API (not the ABI) is just a kludge to move the responsibility to somebody else (those who didn't make the mistake in the first place). -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
10.01.2013 18:55, Max Kellermann пишет: This looks like the worst possible solution. Sure, it reduces the complexity of a possible libmpdclient solution, but that complexity has not disappeared - it is just being moved (and multiplied) to every single application. And it doesn't even have much to do with our current problem. Our problem is that we didn't use the proper data type for sockets on WIN32, and we can't fix this without modifying the ABI. Diverting the API (not the ABI) is just a kludge to move the responsibility to somebody else (those who didn't make the mistake in the first place). OK, so what's the plan? Just change signature of existing functions and increment the API version? -- 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/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
