Re: Windows Compilation problem
Ok I think I solved my problem but want to make sure it is the correct way to do this. I keep all my code the same except for the calls to ev_io_set(). Instead of passing the socket descriptor as returned by socket() or WSASocket() I convert if first to handle and then pass the handle to ev_io_set... the relevant code looks like: ev_io_set (&client->read_watcher, _open_osfhandle(client->socketfd, 0), EV_READ | EV_ERROR); This works as my client now connects and transmits data to the server (Linux) but is a little ugly. better ways to do this are appreciated... Horacio On Thu, Jun 26, 2008 at 10:28 AM, Horacio Sanson <[EMAIL PROTECTED]> wrote: > On Fri, Jun 6, 2008 at 9:35 AM, Chris Hulbert <[EMAIL PROTECTED]> wrote: >> FYI, i just had the same problem. >> To convert from a socket to a file descriptor, you'll need to use this >> function: >> >> // for win32: convert from socket to file descriptor >> // // http://msdn.microsoft.com/en-us/library/bdts1c9x(VS.71).aspx >> int fd = _open_osfhandle(socket,0); >> > > I just encounter this same error but I am unable to solve it. My > program can create a socket() and actually connect to the server using > connect() but when I start the libev default loop an assertion ocurrs > when it calls _get_osfhandle() on line 716 of ev.c file. > > How exactly am I supposed to use the _open_osfhandle() method as you > mention here?? If I use this method on the socket I get from the > socket() method then all subsequent calls on the socket (i.e. connect, > bind, listen) would return WSAENOTSOCK error. > > Shall I replace all instances of _get_osfhandle() with a call to > _open_sofhandle()?? or am I missing something else?? > > regards > Horacio > >> On Thu, Jun 5, 2008 at 6:23 PM, Marc Lehmann <[EMAIL PROTECTED]> wrote: >>> On Wed, Jun 04, 2008 at 04:29:46PM -0700, Matt Tolton <[EMAIL PROTECTED]> >>> wrote: Any pointers here? The fd that I'm using is a socket obtained from the winsock socket() call. Here is the code used to initialize it: >>> >>> That doesn't work - the libev API requires file descriptors on all >>> platforms. What you pass in is a native opertaing system handle that is >>> not a file descriptor. >>> >> >> ___ >> libev mailing list >> libev@lists.schmorp.de >> http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev >> > ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Windows Compilation problem
On Fri, Jun 6, 2008 at 9:35 AM, Chris Hulbert <[EMAIL PROTECTED]> wrote: > FYI, i just had the same problem. > To convert from a socket to a file descriptor, you'll need to use this > function: > > // for win32: convert from socket to file descriptor > // // http://msdn.microsoft.com/en-us/library/bdts1c9x(VS.71).aspx > int fd = _open_osfhandle(socket,0); > I just encounter this same error but I am unable to solve it. My program can create a socket() and actually connect to the server using connect() but when I start the libev default loop an assertion ocurrs when it calls _get_osfhandle() on line 716 of ev.c file. How exactly am I supposed to use the _open_osfhandle() method as you mention here?? If I use this method on the socket I get from the socket() method then all subsequent calls on the socket (i.e. connect, bind, listen) would return WSAENOTSOCK error. Shall I replace all instances of _get_osfhandle() with a call to _open_sofhandle()?? or am I missing something else?? regards Horacio > On Thu, Jun 5, 2008 at 6:23 PM, Marc Lehmann <[EMAIL PROTECTED]> wrote: >> On Wed, Jun 04, 2008 at 04:29:46PM -0700, Matt Tolton <[EMAIL PROTECTED]> >> wrote: >>> Any pointers here? The fd that I'm using is a socket obtained from >>> the winsock socket() call. Here is the code used to initialize it: >> >> That doesn't work - the libev API requires file descriptors on all >> platforms. What you pass in is a native opertaing system handle that is >> not a file descriptor. >> > > ___ > libev mailing list > libev@lists.schmorp.de > http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev > ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Windows Compilation problem
FYI, i just had the same problem. To convert from a socket to a file descriptor, you'll need to use this function: // for win32: convert from socket to file descriptor // // http://msdn.microsoft.com/en-us/library/bdts1c9x(VS.71).aspx int fd = _open_osfhandle(socket,0); On Thu, Jun 5, 2008 at 6:23 PM, Marc Lehmann <[EMAIL PROTECTED]> wrote: > On Wed, Jun 04, 2008 at 04:29:46PM -0700, Matt Tolton <[EMAIL PROTECTED]> > wrote: >> Any pointers here? The fd that I'm using is a socket obtained from >> the winsock socket() call. Here is the code used to initialize it: > > That doesn't work - the libev API requires file descriptors on all > platforms. What you pass in is a native opertaing system handle that is > not a file descriptor. > ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Windows Compilation problem
On Wed, Jun 04, 2008 at 08:18:09PM -0700, Matt Tolton <[EMAIL PROTECTED]> wrote: > This allowed things to work until a socket was closed and fd_ebadf > (and hence fd_valid) was called, causing another call to note that if ev_ebadf is called then you have a programming bug in your application, namely you close the socket without deregistering the watcher. libev doesn't support registering watchers for invalid file descriptors (think about it, the fd could already be reused >_VALIDATE_CLEAR_OSSERR_RETURN((_osfile(fh) & FOPEN), EBADF, -1); > > Might I ask...what is the _get_osfhandle() call for? It seems like it > is ok to just use the handle returned by socket() in my case. It converts a file descriptor into an osf handle as required by the winsocket select fucntion. Not calling it causes crashes for correctly-written programs. removing the calls to them might work on some windows platforms, but will cause crashes on others, so that is a definite and big no-no. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Windows Compilation problem
On Wed, Jun 04, 2008 at 04:29:46PM -0700, Matt Tolton <[EMAIL PROTECTED]> wrote: > Any pointers here? The fd that I'm using is a socket obtained from > the winsock socket() call. Here is the code used to initialize it: That doesn't work - the libev API requires file descriptors on all platforms. What you pass in is a native opertaing system handle that is not a file descriptor. You have to convert the os handle into a file descriptor first (there is some runtime library function for that whose name escapes me at the moment, search the list archives or msdn). in general, just keep in mind that the API is the same on windows and portable operating systems. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Windows Compilation problem
Hi, I've debugged this a little bit further, and have more information to give. In poking around on the net and in the libev code, I couldn't determine why it was necessary to use _get_osfhandle(). I tried the following experiment, and changed my ev_cpp.cpp to look like this: #include #define EV_FD_TO_WIN32_HANDLE(fh) fh #include "ev_cpp.h" #include This allowed things to work until a socket was closed and fd_ebadf (and hence fd_valid) was called, causing another call to _get_osfhandle(). FYI, the place that that function is crashing is at the following assertion: _VALIDATE_CLEAR_OSSERR_RETURN((_osfile(fh) & FOPEN), EBADF, -1); Might I ask...what is the _get_osfhandle() call for? It seems like it is ok to just use the handle returned by socket() in my case. Thanks, Matt ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Windows Compilation problem
> when I run the program, it is crashing on line 16 of ev.c, in the Sorry, typo. I meant line 716. ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Windows Compilation problem
Hi,
Thanks for the assistance.
I grabbed the current version from CVS and that seemed to fix the
compilation issues, so long as I included io.h manually. However, now
when I run the program, it is crashing on line 16 of ev.c, in the
fd_reify function when it calls _get_osfhandle().
Any pointers here? The fd that I'm using is a socket obtained from
the winsock socket() call. Here is the code used to initialize it:
void initServerSocket() {
int res;
int serverfd = socket(AF_INET, SOCK_STREAM, 0);
if (serverfd == -1)
THROW("socket() failed");
if (!SetSocketNonBlocking(serverfd))
THROW("error setting socket nonblocking");
sockaddr server_addr;
init_sockaddr("0.0.0.0", 5111, &server_addr);
res = bind(serverfd, &server_addr, sizeof(server_addr));
if (res == -1)
THROW("bind() failed");
res = listen(serverfd, 10);
if (res == -1)
THROW("listen() failed");
ev::io * server_watcher = new ev::io;
server_watcher->set(0);
server_watcher->set(serverfd, EV_READ);
server_watcher->start();
LOGI << "Server socket initialized.";
}
Thanks,
Matt
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Windows Compilation problem
On Wed, Jun 04, 2008 at 04:19:36AM -0700, Matt Tolton <[EMAIL PROTECTED]> wrote: > I'm having some trouble getting libev to compile on windows. I am > embedding it as recommended. Here are the errors I receive initially: for the NFDBITS issue, you could try out current CVS, which should contain an (untested) workaround for that. the io.h issue is surprising - with my microsoft sdk, I get those definitions when I include windows.h with WIN32_LEAN_AND_MEAN - why it would require an additional io.h include for you is puzzling. > I poked around and discovered that the "io.h" header has the > unreferenced functions. I added that in my ev_cpp.c file above the > ev.c include. This reduced the errors to the following: I think that's the way to go for the moment. > lib\ev/ev.c(773) : warning C4806: '==' : unsafe operation: no value of type > 'boo > l' promoted to type 'int' can equal the given constant Hmm, that might actually be a real bug... (it is of no consquence as long as libev is used correctly, though). > lib\ev/ev.c(981) : error C2664: 'ioctlsocket' : cannot convert parameter 3 > from > 'int *' to 'u_long *' This is also a bug - could you check out CVS, which will have a possible fix for that as well in a few minutes? (It also doesn't affect correctness, when it compiles, as unsigned long is compatible to int on windows for the values used). > According to the docs, the NFDBITS problem should be fixed by defining > EV_SELECT_USE_FD_SET, which seems to be defined automatically for > windows. It should, but the recent workaround for non-blocking connects apparentlsy reintroduced the dependency on NFDBITS. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Windows Compilation problem
Hi, I'm having some trouble getting libev to compile on windows. I am embedding it as recommended. Here are the errors I receive initially: cl /nologo /TP /Ilib /c src\ev_cpp.cpp /Fobuild\ev_cpp.obj ev_cpp.cpp c:\mud\lib\ev\ev_win32.c(85) : error C3861: '_open_osfhandle': identifier not fo und c:\mud\lib\ev\ev_win32.c(86) : error C3861: '_open_osfhandle': identifier not fo und lib\ev/ev.c(708) : error C3861: '_get_osfhandle': identifier not found lib\ev/ev.c(759) : error C3861: '_get_osfhandle': identifier not found lib\ev/ev.c(773) : warning C4806: '==' : unsafe operation: no value of type 'boo l' promoted to type 'int' can equal the given constant lib\ev/ev.c(981) : error C3861: '_get_osfhandle': identifier not found lib\ev/ev.c(1033) : error C3861: 'write': identifier not found lib\ev/ev.c(1052) : error C3861: 'read': identifier not found c:\mud\lib\ev\ev_select.c(137) : error C2065: 'NFDBITS' : undeclared identifier lib\ev/ev.c(1365) : error C3861: 'close': identifier not found lib\ev/ev.c(1366) : error C3861: 'close': identifier not found lib\ev/ev.c(1376) : error C3861: 'close': identifier not found lib\ev/ev.c(1461) : error C3861: 'close': identifier not found lib\ev/ev.c(1462) : error C3861: 'close': identifier not found I poked around and discovered that the "io.h" header has the unreferenced functions. I added that in my ev_cpp.c file above the ev.c include. This reduced the errors to the following: cl /nologo /TP /Ilib /c src\ev_cpp.cpp /Fobuild\ev_cpp.obj ev_cpp.cpp lib\ev/ev.c(773) : warning C4806: '==' : unsafe operation: no value of type 'boo l' promoted to type 'int' can equal the given constant lib\ev/ev.c(981) : error C2664: 'ioctlsocket' : cannot convert parameter 3 from 'int *' to 'u_long *' Types pointed to are unrelated; conversion requires reinterpret_cast, C- style cast or function-style cast c:\mud\lib\ev\ev_select.c(137) : error C2065: 'NFDBITS' : undeclared identifier According to the docs, the NFDBITS problem should be fixed by defining EV_SELECT_USE_FD_SET, which seems to be defined automatically for windows. Any pointers on this? I am using libev-3.41. Thanks, Matt ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
