Re: CFFileDescriptor fd leak?
Re: CFFileDescriptor fd leak?
- Subject: Re: CFFileDescriptor fd leak?
- From: Dave Keck <email@hidden>
- Date: Thu, 20 Aug 2009 18:58:43 -1000
I shaved down the code from the previous email from code which did indeed add the CFFileDescriptor to the runloop and leaked. However, I did not remove the source from the runloop manually like you do above and the Apple example code (http://developer.apple.com/documentation/CoreFoundation/Reference/CFFileDescriptorRef/Reference/reference.html) doesn't remove the runloop source either. Unfortunately, the code you laid out above does indeed sometimes leak a single kqueue fd (OS 10.5.8):
davekeck 4880 alex 4u KQUEUE count=0, state=0
Woops, I excluded this line in that code:
CFFileDescriptorEnableCallBacks(fileDescriptor, kCFFileDescriptorReadCallBack);
Add that after the CFRunLoopAddSource() line. For me, this always prevents the leaks (also on 10.5.8.) Does that do it for you?
At least it is not leaking threads. Speaking of which, why does each file descriptor need to be watched by a new thread? Not even CFSocketManager is that dumb. In any case, this is looking so bad that I will likely need to implement my own CFFileDescriptor replacement.
I'd imagine creating one thread per monitored CFFD would be significantly easier to implement than creating one centralized thread for every monitored CFFD. Also, a thread blocked in kevent() waiting for an event is going to use very little resources and no (?) CPU time, so I don't see the 1-1 nature being an issue.
Before you go off creating your own version of CFFD, I'd suggest actually using CFFD in a realistic scenario and checking for these leaks. I've been using CFFD for awhile, and it's never posed any issue (granted I haven't been actively searching for these leaks). Are you opening so many files that these leaks would pose an issue? I agree that it's unsettling to see these leaks in such a simple scenario, but implementing your own version of CFFD using a centralized thread etc. is also not an easy task, and that code will just become obsolete once the CFFD leaks are addressed.
And as far as your hack... well, I'd consider that a case of the cure being worse than the symptom. =) Again, are you opening so many files that it warrants such scandalous tactics?
Anyway, I'm going to radar this, and I hope you'll do the same.
David
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden