This may have to do with SO_LINGER option which is (WS_SO_DONTLINGER in winsock)
http://source.winehq.org/source/dlls/winsock/socket.c#L2542 good luck, mishka On 7/13/05, Doug Franklin <[EMAIL PROTECTED]> wrote: > On Wed, 13 Jul 2005 00:18:49 -0400, Scott Loveless wrote: > > > The horse's mouth is here: http://www.winehq.com/ Follow the > > documentation links to > > http://www.winehq.com/site/docs/wine-devel/index and possibly > > http://www.winehq.com/site/docs/wine-devel/part-two > > You're kidding, right? :-) > > I'm trying to chase some bugs I think are tied up in the way the > wineserver process operates itself, and the way resource ownership gets > delegated between wineserver and the various wine-preloader instances. > For instance, we've found that when our Windows code calls > closesocket() on a SOCK_STREAM socket (but not on a SOCK_DGRAM socket), > wineserver refuses to actually close and release the socket for several > minutes, so if you stop our app, you can't start it for several > minutes, or its bind() or listen() call will fail because the socket we > closed still exists and still owns the port. > > The docs I've found at winehq have been less helpful than the comments > in the code, which are unhelpful enough. A lot of what and how, very > little of why and when. But I'm still digging through them. I'm > afraid I'm going to have to get even more up close and personal with > the source. I'm trying desperately to avoid that. I _really_ don't > want to be the expert about WINE around the office. :-) > > TTYL, DougF KG4LMZ > > >
