Paolo Bonzini <bonz...@gnu.org> writes: >>> Conceptually this is extremely simple, and I've found that gnulib >>> already contains useful bits like SOCKET_TO_FD, FD_TO_SOCKET, and the >>> code for determining if an arbitrary fd is a socket - which is all >>> great. >> >> Yes, and the read() and write() functions don't need to make this >> distinction, because they call ReadFile and WriteFile, which work >> equally fine with HANDLEs and SOCKETs.
Thanks Bruno. I hope I understood your reply correctly. What I took from it was that read() and write() only don't work when they are called with the wrong type of ID - i.e. a SOCKET instead of a file descriptor - and that they are fine so long as the correct ID conversion is done, using _open_osfhandle(). I hope that's correct. > ... but not for all sockets, only those created by gnulib's socket: > > /* We have to use WSASocket() to create non-overlapped IO sockets. > Overlapped IO sockets cannot be used with read/write. */ > fh = WSASocket (domain, type, protocol, NULL, 0, 0); > > Neil, can you make sure that all your sockets are gnulib-created? I'm not sure. Guile's API, on both C and Scheme level, reflects the traditional Unix/Linux sockets API, which I believe has no equivalent of Windows' overlapped operation. So in that sense Guile has no requirement to support overlapped sockets. However... - MSDN says [1] that a non-blocking socket must be overlapped (if I'm understanding the article correctly), and it would be quite undesirable for Guile to exclude non-blocking socket operation on MinGW. [1] http://support.microsoft.com/kb/181611 - Guile's C API allows constructing a Scheme port around an arbitrary file descriptor - so ideally that would still work for any kind of Windows socket for which it's possible to obtain a file descriptor. Can you let me know your thoughts on those points? Thanks, Neil
