What seems to happen is that when I'm within the 'main' ruby dll sockets work like a champ, then when control transfers to the libev side for some reason all socket functions don't work. You can't even bind to a fresh socket there or anything.
My latest guess is that there is some inconsistency with linking to -lws2_32 within two separate .so files and expecting sockets to work within both. Tough to tell though. Oh well...cruddy wiindows :) -=R On Wed, Nov 12, 2008 at 2:40 AM, Roger Pack <[EMAIL PROTECTED]> wrote: > Note that for some reason, adding those extra includes fixed it for > "normal" build in mingw but broke an embedded build using the same. > Odd. > >>> And for some reason it didn't give me a base by default so I had to >>> hard code in EV_USE_SELECT >> >> What's a base? >> >> Did you run configure when building the library or was it somehow >> embedded? In the latter case, the embedding app has to provide configuraiton >> somehow. > > heh guess it's called a backend. This is with msys configure. > Adding the > > #define EV_STANDALONE /* keeps ev from requiring config.h */ > #define EV_SELECT_IS_WINSOCKET 1 /* configure libev for windows select */ > > to event.c/ev.c seemed to force it to work :) > [on non-embedded] > >> A quick google search about mingw didn't give me a decisive result on what >> type sockets have, but I have the impression that it uses operating system >> handles (HANDLE, SOCKET), not file descriptors (int). >> >> Since windows doesn't seem to have a standard API (mingw is incompatible >> to pure win32 is incompatible to posix is incompatible to cygwin etc.), >> libev needs to be told how the environment converts file descriptors to >> socket handles (_get_osfhandle) and how to get file descriptors out of >> socket handles (e.g. _open_osfhandle). > > Wow you made that easy on me :) > adding > > #define EV_FD_TO_WIN32_HANDLE(s) (s) > to the top of ev.c helped it now work! Rock on! > > Unfortunately this doesn't seem to work when used with rev--rev > currently creates a TCPServer socket within ruby, then passes an fd > representing that socket to libev--I'm not sure why but running the > ioctlsocket test on it returns -1 with wsagetlasterror 10038 > (WSAENOTSOCK). > Odd. I'm pretty sure it's creating the sockets deep within ruby with > 'socket' or WSASocket or the like. Ruby can select on them just fine. > Hmm. > > Thoughts? > > Thanks for your time. > > -=R _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
