Re: read() and write() for MinGW

[Neil Jerram]

Paolo Bonzini <address@hidden> 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