>> There's no finalizer on the Socket class that closes it so that even
>> if it is garbage collected, the socket is not closed at the OS level.
>> I think I saw somewhere this was done by design and actually I believe
>> it's much cleaner to properly close the socket before losing any
>> reference to it so that OS resources are freed as early as possible.
>> Much better for scalability ;-)
>
Our experience here seems to agree with this fact. Either tcp conns
aren't close by the GC or it takes too long to do just that. In both
cases, we ended with connection leaks.
> "By design," huh? We call such thinking: bugs on purpose (also known to
> the anti-MSFT crowd as windows programming). <smile>
>
LOL. I tend to define it as "lazy programming". Like those days in
college, when we had to write code that needed to survive only a
few minutes, while being screened and tested by our teachers...
And that's why I prefer to write code in C. There isn't any
Wizard of Oz to do things for you, so, you'd better free your
memory by yourself [and close your connections, too].
> Yes, it's best to clean up. But no, a finalizer should discard any open
> resources as that what it was designed for. After all, if the object is
> GCed, then nobody is using it, so nobody ever will close it. At any
> rate, sounds like the PG team has already fixed the leak in its code.
> Thanks guys.
>
Yes, a finalizer should take care (or better care, we just don't know)
of this issue. But we're living in a real world, where apps have bugs
or design glitches.... Maybe the connection is still referenced by
internal (or not so visible) structures so they're never closed/freed
automagically.