[jdev] Bug in jabberd2 (2.1.13) on win32

[Dan Hulme]

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/
> >
>