[jdev] Bug in jabberd2 (2.1.13) on win32
Dan Hulme
dhulme at gmail.com
Thu Jan 24 17:01:18 CST 2008
Although that patch does seem to work, I'm completely sure it ever
frees the mio struct. Thus, I think the zeroing the event method is
better.
-Dan
On Jan 24, 2008 2:15 PM, Dan Hulme <dhulme at gmail.com> wrote:
> Ok, after looking closer, it does not appear to reuse sockets at all,
> but reuses the mio structure. The structure is pretty simple and was
> not remembering the old file descriptor, so I just looked at how it
> differed (after being used once) from a completely new one. What I
> noticed was that the "revent" and "event" fields were not being reset
> on freeing it for reuse. I zeroed them (it seems only the event must
> be cleared):
>
> mio_wsasync.h:68
> static void _mio_free_fd(mio_t m, mio_priv_fd_t priv_fd) \
> { \
> priv_fd->next_free = MIO(m)->next_free; \
> priv_fd->mio_fd.fd = 0; \
> priv_fd->revent = 0; \
> priv_fd->event = 0; \
> MIO(m)->next_free = priv_fd; \
> } \
>
> And the bug goes away. Since the socket is available for reuse, it
> doesn't make sense to remember the old event flags. This may mean that
> an event may arrive that doesn't get handled, of course, but if it
> *is* to be handled, the mio struct should not be marked as available
> until the event is handled.
>
> In this vein, I have provided a patch which does nothing when
> _mio_free_fd is called, but frees it when the FD_CLOSE is received.
> It's attached. It basically replaces mio_free_fd with a dummy
> function and moves the functionality to another function.
>
> -Dan
>
>
>
>
> On Jan 24, 2008 11:25 AM, Dan Hulme <dhulme at gmail.com> wrote:
> > I had forgotten, but this is the case. Here is confirmation:
> >
> > http://msdn2.microsoft.com/en-us/library/ms740481(VS.85).aspx
> > > An application should not rely on being able to reuse a socket after it has been shut down.
> > > In particular, a Windows Sockets provider is not required to support the use of
> > > 'connect' on a socket that has been shut down.
> >
> > So the win32 implementation should not be pooling sockets, I guess.
> >
> > -Dan
> >
> >
> > On Jan 24, 2008 12:51 AM, Norman Rasmussen <norman at rasmussen.co.za> wrote:
> > > On Jan 24, 2008 2:14 AM, Dan Hulme <dhulme at gmail.com> wrote:
> > >
> > > > This function appears to try to append the old closed socket to a
> > > > linked list of free sockets. When the new connection tries to use
> > > > this socket, it has trouble. Once the next connection connects,
> > > > however, it will not use that socket as it is still in use, so it will
> > > > work. Not sure why the socket that is being appended is broken, but
> > > > if this function is not called (at mio_impl.h: 267), the program works
> > > > "fine." It may not be reusing sockets, but everything else works.
> > > >
> > >
> > > In my experience win32 does weird things with closed sockets: if you close a
> > > listening socket, it doesn't actually go away until all connected clients do
> > > too. It sounds like this is similar, and that perhaps for win32 you
> > > shouldn't be trying to pool sockets.
> > >
> > > --
> > > - Norman Rasmussen
> > > - Email: norman at rasmussen.co.za
> > > - Home page: http://norman.rasmussen.co.za/
> >
>
More information about the JDev
mailing list