Using libev with Windows sockets

[Eric Fowler]

I have inherited a pretty large Linux-based server project and am tasked with porting it to Windows. It is heavily dependent upon libev and libeio.


(1)    - I have noticed that libev uses socket descriptors as array indexes in several places. This is fine on Linux because the socket descriptors are always small (typical values range from 4 to 8 for small numbers of sockets). However, Windows socket handles have integer values starting at nearly 200, with the high value undefined. This would seem to make them useless as array indices. Am I justified in my concern or is there something about Winsock or libev that I am not seeing?

(2)    - Our code is getting a Windows socket descriptor and passing it down into libev, where it comes a-cropper on an EV_FD_TO_WIN32_HANDLE() macro in ev.c!fd_reify() [line 2084]. I am not surprised that the macro choked; it is trying to convert a windows socket descriptor to a windows socket descriptor, which should not be expected to work. The bigger question is, 'What am I doing wrong?' Should I not expect the libev code to *ever* see a windows socket handle? There must be some design strategy WRT windows handles here, but I am not seeing it. The code is within an #ifdef block that expects Windows ... does this mean it does not expect to see windows handles? Is there a simple way to fish a BSD style socket descriptor out of a windows socket handle?

Thanks very much

WW

________________________________
The information in this email, and any attachments, may contain confidential information and is intended solely for the attention and use of the named addressee(s). It must not be disclosed to any person(s) without authorization. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorized to, and must not, disclose, copy, distribute, or retain this message or any part of it. If you have received this communication in error, please notify me immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20160511/b3898334/attachment.html>