[jdev] Bug in jabberd2 (2.1.13) on win32

[Dan Hulme]

err, "not completely sure"

On Jan 24, 2008 3:01 PM, Dan Hulme <dhulme at gmail.com> wrote:
> 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/
> > >
> >
>