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
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
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
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.
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
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
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
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
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..
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.
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
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
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
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
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
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?
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
17 matches
Mail list logo
