Prev: copy text on the screen as text?
Next: read from TCP/IP socket with blocking
From: Rick Parrish on 27 Jan 2010 10:49
> Quite frankly, that is an _awful_ solution.  It is entirely
> implementation dependent, and likely to fail to work in some future
> version of .NET.  It definitely is "as questionable as" using
> Thread.Sleep().

Excellent point. This was the first time I'd tried using reflection,
and I was so happy it worked that the thought didn't even occur to me
that it'll likely break down the road. So I've implemented my own
Socket class, and all is well now.

> Of course, even doing that you have failed to take into account the fact
> that the _unmanaged_ object is still effectively managed by the OS, and
> will still be closed at some point after your process exits.  But if for
> some reason not closing it explicitly when your process exits lets it
> live long enough for your purposes, then at least achieve that goal in a
> reliable way.

Maybe I'm wrong, but I would think the OS will let it live until the
parent process has exited as well (which won't happen until some time
after the child process does).
From: Peter Duniho on 27 Jan 2010 13:06
Rick Parrish wrote:
> [...]
>> Of course, even doing that you have failed to take into account the fact
>> that the _unmanaged_ object is still effectively managed by the OS, and
>> will still be closed at some point after your process exits. But if for
>> some reason not closing it explicitly when your process exits lets it
>> live long enough for your purposes, then at least achieve that goal in a
>> reliable way.
>
> Maybe I'm wrong, but I would think the OS will let it live until the
> parent process has exited as well (which won't happen until some time
> after the child process does).

Time will tell.

I admit, I am so skeptical of the overall approach, I haven't really
bothered to look into it in detail. But, the only reason I can think of
that the OS would let a handle in one process stay open after the
process exits is if the OS is specifically tracking how many processes
are using the handle, and on the basis of a count of such processes,
leaves the handle open until the count is 0.

But, if the OS is doing that, I would expect the OS to also use that
logic when any given process closes the handle. This is in fact the
documented behavior for inheritable handles generally. So if you have a
situation where the OS isn't doing what the docs appear to say it would
normally do, I don't think you can count on the OS also doing the same
kind of thing when the handle would be closed implicitly due to process
exit.

However, that's all pure speculation. If it seems to work for you and
you're happy with the solution, go for it. :)

Pete
From: Rick Parrish on 28 Jan 2010 14:34
> I have an application that accepts an existing socket connection
> (passed to it by the server that actually accepted the incoming
> connection), and I'm trying to find a way to have the application NOT
> close the socket when it terminates.

Ironically enough, the way to stop the socket from closing is to call
Socket.Close()!

After much more testing and stepping through code I found
Socket.Dispose() calls shutdown(), and this is what was disconnecting
the user. Calling Socket.Close() will call closesocket() without
calling shutdown(), which leaves the connection open, and so then when
the Socket is disposed, shutdown() doesn't get called since Close()
has already been called.
First  |  Prev  | 
Pages: 1 2 3
Prev: copy text on the screen as text?
Next: read from TCP/IP socket with blocking