• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: CFFileDescriptor fd leak?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • Follow-Ups:
    • Re: CFFileDescriptor fd leak?
      • From: "A.M." <email@hidden>
References: 
 >CFFileDescriptor fd leak? (From: "A.M." <email@hidden>)
 >Re: CFFileDescriptor fd leak? (From: Dave Keck <email@hidden>)
 >Re: CFFileDescriptor fd leak? (From: "A.M." <email@hidden>)

  • Prev by Date: Re: CFFileDescriptor fd leak?
  • Next by Date: Re: 64-bit Mac OS X kernel
  • Previous by thread: Re: CFFileDescriptor fd leak?
  • Next by thread: Re: CFFileDescriptor fd leak?
  • Index(es):
    • Date
    • Thread