Is this situation similar to the real world, when the SO lingers, and
you're just about to get married if you manage to wash your own
winsocks?
Jostein,
just wondering...:-)
----- Original Message -----
From: "Mishka" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, July 14, 2005 3:32 AM
Subject: Re: OT: Linux/WINE
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