[ wxwindows-Patches-1785299 ] wxSocket not closing file descriptors on the Mac

[SourceForge.net]

Patches item #1785299, was opened at 2007-08-30 19:45
Message generated for change (Comment added) made by dan_willemsen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=309863&aid=1785299&group_id=9863

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Socket
Group: bug fix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dan Willemsen (dan_willemsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: wxSocket not closing file descriptors on the Mac

Initial Comment:
I'm using wxMac 2.8.4, and my application is trying to connect to a number of servers when otherwise idle. The problem I'm having is that eventually, I'm running out of available file descriptors when one or more of those servers are not available.

What happens is that I create a wxSocketClient, then call the Connect method with an address that isn't currently on the network. It'll take about a minute to timeout, at which point Connect returns false and I return the error to my loop. No matter whether I leave the wxSocketClient alone, reuse it, close it, or destroy it, I still see the connection when I run Activity Monitor and look at the open file descriptors for my program.

>From what I can tell, the problem resides in GSocket::Close in src/unix/gsocket.cpp

The comments says that:

/* gsockosx.c calls CFSocketInvalidate which closes the socket for us */

Which would be true, if the methods in gsockosx.c were ever called in my application. It's currently just a console application that we're using wxThread and wxSocket in to provide cross platform support to Windows as well.

gs_gui_functions, at least in my case, is set to the Null table, so the code in gsockosx.c is never called.

If I take out the preprocessor #if statement, my sockets get closed properly - I've left my program running for over 24 hours now without problem, where it used to die within an hour.

I've got a patch to tell CFSocket not to close the file descriptor, so that it is always safe to do it in GSocket::Close without the #if. If that is a proper fix, I'll upload it to the patch manager.

Thanks,
Dan Willemsen

----------------------------------------------------------------------

>Comment By: Dan Willemsen (dan_willemsen)
Date: 2007-09-03 17:25

Message:
Logged In: YES 
user_id=716230
Originator: YES

For GUI applications, this patch tells CFSocket to not close on
invalidate, so that it doesn't have to be special cased. I haven't actually
tested this on a GUI application though - my current project is command
line only. Also, only the GUI applications actually use CFSocket, command
line apps just use the regular unix/posix way.

I haven't looked at 2.9 yet, I may take a look later.

----------------------------------------------------------------------

Comment By: Kevin Hock (hockkn)
Date: 2007-09-03 15:47

Message:
Logged In: YES 
user_id=801586
Originator: NO

But what is the effect of this patch on GUI applications? It seems like in
a GUI build, it would get closed twice, once by close and once by
CFSocketInvalidate (maybe that's harmless). That would need to be tested
before this should be applied. And what happens when all of these sockets
never get Invalidated on Base?

I also recall that 2.9 now offers enhanced socket functionality on wxBase,
how does this change mesh with that? Is this change even necessary on 2.9,
or does it already work?

----------------------------------------------------------------------

Comment By: Dan Willemsen (dan_willemsen)
Date: 2007-08-30 19:51

Message:
Logged In: YES 
user_id=716230
Originator: YES

Whoops, thought I was putting this in the bug tracker, I'm uploading the
patch, since I posted in the Patch tracker
File Added: gsocket.mac.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=309863&aid=1785299&group_id=9863