On Sun, Feb 20, 2005 at 06:24:17AM -0500, Jeff Trawick wrote: > On Fri, 18 Feb 2005 18:45:39 -0800, Henry Jen <[EMAIL PROTECTED]> wrote: > > > Attached patch fix a bug on Win32, if call apr_recvfrom() when no one > > write to that addr:port, the call returns 730022(WSAEINVAL) instead of > > blocking as expected. > > > > The reason is that the from->salen was not initialized properly. The > > patch fix the problem. > > I'm trying to figure out why that field isn't yet set when you call > apr_recvfrom(). >
Hmm, I am using a apr_sockaddr_t from stack without initialize it first. That's what went wrong. I should have initialized it first. However, I think to reset the value maybe not a bad idea as that's an input/output field. > First you call apr_socket_create(), which calls apr_socket_create_ex(). > apr_socket_create_ex() calls set_socket_vars(*new, family, type, protocol). > set_socket_vars() calls apr_sockaddr_vars_set(sock->remote_addr, family, 0). > apr_sockaddr_vars_set() will set addr->salen to sizeof(struct sockaddr_in). > This is not about apr_socket_t, it's apr_sockaddr_t(first parameter) for calling apr_socket_recvfrom. Unless you are suggesting me to use the remote_addr from apr_socket_t. If that's the idea, why do we need to passed in the apr_sockaddr_t in the first place? > Can you tell me where this breaks in your situation? (i.e., why > didn't apr_sockaddr_vars_set() set from->salen to the proper value > before you called apr_socket_recvfrom()?) > I use an apr_sockaddr_t from stack without initialize it. :-) > Thanks, > Thank you for looking into it. :-) Henry
