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





Reply via email to