Re: dealloc and scarce resources
On Wed, Jun 29, 2011 at 10:38 PM, James Merkel jmerk...@mac.com wrote: Ok, thanks. For what I'm doing file descriptors are not a scarce resource. File descriptors are almost always a scarce resource. By default, each process only gets 256 of them. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 29, 2011, at 11:07 PM, Kyle Sluder wrote: On Wed, Jun 29, 2011 at 10:38 PM, James Merkel jmerk...@mac.com wrote: Ok, thanks. For what I'm doing file descriptors are not a scarce resource. File descriptors are almost always a scarce resource. By default, each process only gets 256 of them. --Kyle Sluder Ok, I'm looking at my application in Instruments File Activity. The column labeled FD I assume means file descriptors. Is that the total number of FDs in use at any given time? Jim Merkel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
Le 30 juin 2011 à 08:19, James Merkel a écrit : On Jun 29, 2011, at 11:07 PM, Kyle Sluder wrote: On Wed, Jun 29, 2011 at 10:38 PM, James Merkel jmerk...@mac.com wrote: Ok, thanks. For what I'm doing file descriptors are not a scarce resource. File descriptors are almost always a scarce resource. By default, each process only gets 256 of them. --Kyle Sluder Ok, I'm looking at my application in Instruments File Activity. The column labeled FD I assume means file descriptors. Is that the total number of FDs in use at any given time? No, Just like process ID, file descriptor number can be reused by the system. And there is absolutely no guarantee the system use simple incremental value for fd AFAIK. -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 3:02 AM, Jean-Daniel Dupas wrote: Le 30 juin 2011 à 08:19, James Merkel a écrit : Ok, I'm looking at my application in Instruments File Activity. The column labeled FD I assume means file descriptors. Is that the total number of FDs in use at any given time? No, Just like process ID, file descriptor number can be reused by the system. That analogy is a bit flawed. Process IDs are global across the system. File descriptors are per-process. And there is absolutely no guarantee the system use simple incremental value for fd AFAIK. Actually, when a new file descriptor is created for your process, it does use the lowest unused descriptor number (except for dup2()). Still, the File Activity instrument's event list isn't showing a count of file descriptors, it's showing the specific individual file descriptor involved in the specific event. But there's a pretty good chance that the highest file descriptor you see across a significant range of events roughly indicates the count of open descriptors. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 2:01 AM, Ken Thomases wrote: On Jun 30, 2011, at 3:02 AM, Jean-Daniel Dupas wrote: Le 30 juin 2011 à 08:19, James Merkel a écrit : Ok, I'm looking at my application in Instruments File Activity. The column labeled FD I assume means file descriptors. Is that the total number of FDs in use at any given time? No, Just like process ID, file descriptor number can be reused by the system. That analogy is a bit flawed. Process IDs are global across the system. File descriptors are per-process. And there is absolutely no guarantee the system use simple incremental value for fd AFAIK. Actually, when a new file descriptor is created for your process, it does use the lowest unused descriptor number (except for dup2()). Still, the File Activity instrument's event list isn't showing a count of file descriptors, it's showing the specific individual file descriptor involved in the specific event. But there's a pretty good chance that the highest file descriptor you see across a significant range of events roughly indicates the count of open descriptors. Regards, Ken That's kind of what I concluded -- that the FD is roughly the current number of file descriptors. I noticed that sometimes the FD shows -1, but that's only in a transient condition. I attribute that to Instruments not being able to keep up. It never settles down to -1. After a fair amount of application warm-up the FD shows 25 to 26. So, I assume I'm ok. The FD has a pattern similar to memory in use. It grows for a while when you start and use an application, then settles out to some value. If it grows continually I guess you have a problem. In order not to get a fire-hose amount of data, you can type in a file-name (or some other identifier) into the spotlight-like magnifier box in the lower right corner of the Instruments window. Then you are looking at only files of interest. Again this sort of works, but Instruments still may not show everything. Jim Merkel___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 9:20 AM, James Merkel wrote: On Jun 30, 2011, at 2:01 AM, Ken Thomases wrote: On Jun 30, 2011, at 3:02 AM, Jean-Daniel Dupas wrote: Le 30 juin 2011 à 08:19, James Merkel a écrit : Ok, I'm looking at my application in Instruments File Activity. The column labeled FD I assume means file descriptors. Is that the total number of FDs in use at any given time? No, Just like process ID, file descriptor number can be reused by the system. That analogy is a bit flawed. Process IDs are global across the system. File descriptors are per-process. And there is absolutely no guarantee the system use simple incremental value for fd AFAIK. Actually, when a new file descriptor is created for your process, it does use the lowest unused descriptor number (except for dup2()). Still, the File Activity instrument's event list isn't showing a count of file descriptors, it's showing the specific individual file descriptor involved in the specific event. But there's a pretty good chance that the highest file descriptor you see across a significant range of events roughly indicates the count of open descriptors. Regards, Ken That's kind of what I concluded -- that the FD is roughly the current number of file descriptors. I noticed that sometimes the FD shows -1, but that's only in a transient condition. I attribute that to Instruments not being able to keep up. It never settles down to -1. After a fair amount of application warm-up the FD shows 25 to 26. So, I assume I'm ok. The FD has a pattern similar to memory in use. It grows for a while when you start and use an application, then settles out to some value. If it grows continually I guess you have a problem. In order not to get a fire-hose amount of data, you can type in a file-name (or some other identifier) into the spotlight-like magnifier box in the lower right corner of the Instruments window. Then you are looking at only files of interest. Again this sort of works, but Instruments still may not show everything. Jim Merkel After looking some more at Instruments File Activity, I see that the FD can end up in a static state with an FD of -1. I'm not sure what that means. However I think Ken Thomases' statement is correct: Still, the File Activity instrument's event list isn't showing a count of file descriptors, it's showing the specific individual file descriptor involved in the specific event. But there's a pretty good chance that the highest file descriptor you see across a significant range of events roughly indicates the count of open descriptors. You can sort on the FD column and find the largest FD, so that's pretty easy to find. I notice that the Instruments documentation (User Guide) doesn't explain these things, at least as far as I could tell. Maybe you're just supposed to know this (from birth I guess). Jim Merkel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Thu, Jun 30, 2011 at 9:20 AM, James Merkel jmerk...@mac.com wrote: After a fair amount of application warm-up the FD shows 25 to 26. So, I assume I'm ok. And what happens when (not if) you introduce a leak, and these objects live longer than you expect them to? Or worse, someone else starts holding on to these objects? You're already using an -invalidate method. You just happened to call it -dealloc. Why not follow good defensive programming practice and make it explicit to save yourself future headaches? --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 12:04 PM, Kyle Sluder wrote: On Thu, Jun 30, 2011 at 9:20 AM, James Merkel jmerk...@mac.com wrote: After a fair amount of application warm-up the FD shows 25 to 26. So, I assume I'm ok. And what happens when (not if) you introduce a leak, and these objects live longer than you expect them to? Or worse, someone else starts holding on to these objects? You're already using an -invalidate method. You just happened to call it -dealloc. Why not follow good defensive programming practice and make it explicit to save yourself future headaches? --Kyle Sluder Ok, I don't know what an -invalidate method is, but I'll look it up. Jim Merkel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Thu, Jun 30, 2011 at 12:12 PM, James Merkel jmerk...@mac.com wrote: Ok, I don't know what an -invalidate method is, but I'll look it up. It's the thing Wim talked about. An explicit way to release the scarce resource you're holding on to. Depending on what that resource is, an appropriate name might be -close, or -invalidate, or -terminate. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 12:21 PM, Kyle Sluder wrote: On Thu, Jun 30, 2011 at 12:12 PM, James Merkel jmerk...@mac.com wrote: Ok, I don't know what an -invalidate method is, but I'll look it up. It's the thing Wim talked about. An explicit way to release the scarce resource you're holding on to. Depending on what that resource is, an appropriate name might be -close, or -invalidate, or -terminate. --Kyle Sluder I saw that in Wlm's post. However, I'm not sure where I would do that. I'll have to think about it some more. By the way my original post referred to the Memory Management Programming Guide and the statement: You should typically not manage scarce resources such as file descriptors, network connections, and buffers or caches in a dealloc method. I was pretty sure that file descriptors referred to something at a lower level, but wasn't sure. Maybe I'm being pedantic, but Apple could have helped things along by saying: You should typically not manage scarce resources such as Unix file descriptors, ... Everyone doesn't approach this stuff with the same background. We find from Kernighan and Ritchie (KR) second edition, section 8.1 that a file descriptor is a small non-negative integer that refers to a file and is maintained by the system. So, my guess is that when Instruments shows an FD of -1 it refers to an FD that isn't mine. But that's just a guess. Instruments doesn't document this as far as I know. Jim Merkel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On 2011 Jun 30, at 13:33, James Merkel wrote: I'm not sure where I would do that [-invalidate, releaseResources, removeObservers, whatever] That's a common dilemma. There is no general solution. Each situation will have its own least-worst solution. Apple could have helped things along by saying… Please scroll down to the bottom, Did this document help you?, and click Not helpful… ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 1:33 PM, James Merkel wrote: We find from Kernighan and Ritchie (KR) second edition, section 8.1 that a file descriptor is a small non-negative integer that refers to a file and is maintained by the system. Actually file descriptors are used for any sort of I/O channel, including the default stdin/stdout/stderr streams, network sockets, IPC connections, and more. Running out of them is less uncommon than you’d think, so it’s a good idea to close unneeded ones ASAP. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
James Merkel wrote: Everyone doesn't approach this stuff with the same background. We find from Kernighan and Ritchie (KR) second edition, section 8.1 that a file descriptor is a small non-negative integer that refers to a file and is maintained by the system. Wikipedia is also a useful reference. When I select the words file descriptors on a web page, contextual- click it (right click, secondary click, control click), then choose Search with Google from the contextual menu, Wikipedia's page is the top hit. -- GG ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Thu, Jun 30, 2011 at 7:06 PM, Greg Guerin glgue...@amug.org wrote: James Merkel wrote: Everyone doesn't approach this stuff with the same background. We find from Kernighan and Ritchie (KR) second edition, section 8.1 that a file descriptor is a small non-negative integer that refers to a file and is maintained by the system. Wikipedia is also a useful reference. When I select the words file descriptors on a web page, contextual-click it (right click, secondary click, control click), then choose Search with Google from the contextual menu, Wikipedia's page is the top hit. Wikipedia is hardly the definitive reference. SEO comes to mind. The following was one of the best I've seen, where Dr. Adler is asked to explain why his reference implementation differs from Wikipedia: This is going out the Mr. Adler, his friends at zlib, the related newsgroups comp.compression and sci.crypt, and the newsgroups sci.math and sci.math.num-analysis... This post relates to suspect calculations... The algorithm is described in the last parts of RFC 1950 and at its Wikipedia page (http://en.wikipedia.org/wiki/Adler-32). [1] Jeff [1] Need peer review: May have found mistake in Adler-32!, http://groups.google.com/group/comp.compression/browse_thread/thread/5a37a9fcd32786fd/9859a0c61a3fb333 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
Jeffrey Walton wrote: Wikipedia is hardly the definitive reference. SEO comes to mind. Luckily, I didn't say Wikipedia was a definitive reference. I said useful reference. And anyone at all familiar with it knows full well that its accuracy (and usefulness) can vary widely. I, for one, would never use it as a definitive reference for any algorithm, though I may well use its links at the end of an article to begin my search for definitive references. My main point was more that there is a very easy way to search for unknown terms that one encounters when reading documentation on the web. This is on the same level as pointing out that nearly every reference page on developer.apple.com has Feedback buttons at the bottom of the page, where complaints about unknown terms can easily be filed. -- GG ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 3:33 PM, James Merkel wrote: So, my guess is that when Instruments shows an FD of -1 it refers to an FD that isn't mine. What the File Activity instrument is showing in its event list is a certain subset of system calls which operate on file descriptors. It is showing each call. When one of those events shows a file descriptor of -1, it typically means that call failed, because system calls which return file descriptors typically return -1 (or other negative number) to indicate failure. By the way, since File Activity is only monitoring a subset of file-descriptor-related system calls, you can't necessarily use it to track leaks of file descriptors. I have opened a bug report with Apple about the need for an instrument which tracks all file descriptor activity, but it hasn't had any response. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Thu, Jun 30, 2011 at 6:34 PM, James Merkel jmerk...@mac.com wrote: Then wherever I was sending the -release, I need to also send a separate -close. it could be before or after the release, it doesn't really matter. No, it really needs to be before the -release. When you call -release, you relinquish your ownership of that object. It may cease to exist at that point. It may continue to live for an indeterminate amount of time. But either way, yes, it's one method call, done before the call to -release. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 6:39 PM, Kyle Sluder wrote: On Thu, Jun 30, 2011 at 6:34 PM, James Merkel jmerk...@mac.com wrote: Then wherever I was sending the -release, I need to also send a separate -close. it could be before or after the release, it doesn't really matter. No, it really needs to be before the -release. When you call -release, you relinquish your ownership of that object. It may cease to exist at that point. It may continue to live for an indeterminate amount of time. But either way, yes, it's one method call, done before the call to -release. --Kyle Sluder Ok, doing the -close first makes more sense. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
dealloc and scarce resources
In another thread, someone referenced the Memory Management Programming Guide: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ MemoryMgmt/Articles/mmPractical.html%23//apple_ref/doc/uid/ TP40004447-1000922-BABBFBGJ In the Guide it says: You should typically not manage scarce resources such as file descriptors, network connections, and buffers or caches in a dealloc method. In particular, you should not design classes so that dealloc will be invoked when you think it will be invoked. Invocation of dealloc might be delayed or sidestepped, either because of a bug or because of application tear-down. Instead, if you have a class whose instances manage scarce resources, you should design your application such that you know when you no longer need the resources and can then tell the instance to “clean up” at that point. You would typically then release the instance, and dealloc would follow, but you will not suffer additional problems if it does not. In my code I close a file in the dealloc method -- so I guess that's a file descriptor. I opened the file in the init method, so it seemed logical to close it in the dealloc method. Also, not to be facetious, if I have a bug in my code, wouldn't I fix it? Granted, at application tear-down, if the file is still open, it won't be closed because dealloc won't be called. But again that comes under the heading of a bug in the code. So I don't understand this injunction. Jim Merkel___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On 29 Jun 2011, at 5:43 PM, James Merkel wrote: In the [Memory Management Programming Guide] it says: You should typically not manage scarce resources such as file descriptors, network connections, and buffers or caches in a dealloc method. In particular, you should not design classes so that dealloc will be invoked when you think it will be invoked. Invocation of dealloc might be delayed or sidestepped, either because of a bug or because of application tear-down. Instead, if you have a class whose instances manage scarce resources, you should design your application such that you know when you no longer need the resources and can then tell the instance to “clean up” at that point. You would typically then release the instance, and dealloc would follow, but you will not suffer additional problems if it does not. In my code I close a file in the dealloc method -- so I guess that's a file descriptor. I opened the file in the init method, so it seemed logical to close it in the dealloc method. Also, not to be facetious, if I have a bug in my code, wouldn't I fix it? Granted, at application tear-down, if the file is still open, it won't be closed because dealloc won't be called. But again that comes under the heading of a bug in the code. So I don't understand this injunction. I don't think it should be treated as a hard rule, but I think it is good advice most of the time, or at least a good starting position. One way to look at it is that for most objects you're not supposed to assume very much about their lifetime. You know they exist as long as you have a refcount to them, but they *may* continue to exist after you release them. This is the semantic of -release. You may happen to know, in a particular piece of code, that you have the only reference to something and it will be dealloced with a given release. But thinking of release as equivalent to dealloc will get you into trouble. Even ignoring GC (which makes dealloc/finalize even more uncertain), you might end up stashing a reference to that object somewhere else, extending its lifetime. Maybe it's in an NSNotification or an undo stack or a debug log, or there's a situation where your autorelease pool lasts longer than you expect (perhaps you are dealing with a bunch of files in a loop as you load or save a document, eg). In my experience it isn't *usually* a problem of leaking the file handles entirely; it's a problem if I temporarily accumulate too many of them, or if I need the file handle (or socket or...) to be closed before I do some operation, and simply calling -release isn't normally a guarantee of that. My preferred approach is to have a -close or -invalidate method that releases resources, breaks retain cycles, etc.. If -invalidate isn't called before dealloc, that's OK, but I can also call -invalidate explicitly if I know I want to tear down the object at a given time. I think there are cases where the indefinite lifetime *is* what you want, if you have objects that can lazily fault something in from disk, or which encapsulate a sharable server connection, or etc. But those objects should be the exception, so that you can be especially aware of lifecycle issues in any code that deals with them. And even so, I usually end up having to give them an -invalidate method eventually, to deal with some odd situation. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 29, 2011, at 7:17 PM, Wim Lewis wrote: On 29 Jun 2011, at 5:43 PM, James Merkel wrote: In the [Memory Management Programming Guide] it says: You should typically not manage scarce resources such as file descriptors, network connections, and buffers or caches in a dealloc method. In particular, you should not design classes so that dealloc will be invoked when you think it will be invoked. Invocation of dealloc might be delayed or sidestepped, either because of a bug or because of application tear-down. Instead, if you have a class whose instances manage scarce resources, you should design your application such that you know when you no longer need the resources and can then tell the instance to “clean up” at that point. You would typically then release the instance, and dealloc would follow, but you will not suffer additional problems if it does not. In my code I close a file in the dealloc method -- so I guess that's a file descriptor. I opened the file in the init method, so it seemed logical to close it in the dealloc method. Also, not to be facetious, if I have a bug in my code, wouldn't I fix it? Granted, at application tear-down, if the file is still open, it won't be closed because dealloc won't be called. But again that comes under the heading of a bug in the code. So I don't understand this injunction. I don't think it should be treated as a hard rule, but I think it is good advice most of the time, or at least a good starting position. One way to look at it is that for most objects you're not supposed to assume very much about their lifetime. You know they exist as long as you have a refcount to them, but they *may* continue to exist after you release them. This is the semantic of -release. You may happen to know, in a particular piece of code, that you have the only reference to something and it will be dealloced with a given release. But thinking of release as equivalent to dealloc will get you into trouble. Even ignoring GC (which makes dealloc/finalize even more uncertain), you might end up stashing a reference to that object somewhere else, extending its lifetime. Maybe it's in an NSNotification or an undo stack or a debug log, or there's a situation where your autorelease pool lasts longer than you expect (perhaps you are dealing with a bunch of files in a loop as you load or save a document, eg). In my experience it isn't *usually* a problem of leaking the file handles entirely; it's a problem if I temporarily accumulate too many of them, or if I need the file handle (or socket or...) to be closed before I do some operation, and simply calling -release isn't normally a guarantee of that. My preferred approach is to have a -close or -invalidate method that releases resources, breaks retain cycles, etc.. If -invalidate isn't called before dealloc, that's OK, but I can also call -invalidate explicitly if I know I want to tear down the object at a given time. I think there are cases where the indefinite lifetime *is* what you want, if you have objects that can lazily fault something in from disk, or which encapsulate a sharable server connection, or etc. But those objects should be the exception, so that you can be especially aware of lifecycle issues in any code that deals with them. And even so, I usually end up having to give them an -invalidate method eventually, to deal with some odd situation. I guess I do think of the delloc being called as a result of my release -- and that seems to be the way it is working. The approach I'm using now is to open the file in an init method, then read a few 100 bytes of header in another method, then find pointers to read other portions of the file and read some more data, then close the file in the dealloc method. Lazy loading of data is an Objective - C/Cocoa pattern. The alternative would be to open the file, read the entire file, and close it in the init method. I guess this is the approach used by NS methods such as: initWithContentsOfFile, etc. However, the file could be megabytes in size, and so this would be considerably slower. Another alternative would be to not use a class but just use C functions to do this, but that wouldn't be a Cocoa pattern at all. Bottom line though, what are the consequences of leaving a file open? When does it finally get closed? Jim Merkel___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 29, 2011, at 17:43, James Merkel wrote: You should typically not manage scarce resources such as file descriptors, network connections, and buffers or caches in a dealloc method. In particular, you should not design classes so that dealloc will be invoked when you think it will be invoked. Invocation of dealloc might be delayed or sidestepped, either because of a bug or because of application tear-down. Instead, if you have a class whose instances manage scarce resources, you should design your application such that you know when you no longer need the resources and can then tell the instance to “clean up” at that point. You would typically then release the instance, and dealloc would follow, but you will not suffer additional problems if it does not. In my code I close a file in the dealloc method -- so I guess that's a file descriptor. I opened the file in the init method, so it seemed logical to close it in the dealloc method. It's only logical to close the file descriptor in dealloc if it's not a scarce resource. The word scarce is vital to this question. Here's a simple (though contrived) example. Suppose you have a loop that's compressing image files. In each iteration of the loop, you open one file for reading and create a new file from it. Let's suppose you've invented objects to represent the source and destination files, and each of these object contains a file descriptor for its open file. It's not hard to imagine, for example, that for unrelated reasons your file-reading object ends up in the autorelease pool. Thus, these objects will build up till the loop exits. If you free the file descriptor in dealloc, and you have to convert 100,000 files, you're going to need 100,000 file descriptors, because you can't recycle file descriptors because dealloc isn't being called until the end of the whole operation. That obviously isn't going to work, since the kernel can create only a very limited number of simultaneous file descriptors. In this case, the recommended solution is to give your object a 'releaseResources' method that will free up its file descriptor. This is the scenario that the above warning is talking about. Note that if scarcity isn't an issue, if there could be as many simultaneous file descriptors as you choose to create, then this pattern isn't necessary***. In real life applications, causes of deferral of dealloc can be really hard to figure out deterministically. Thus it can be hard to know whether you *need* a 'releaseResources' pattern or not. That's why the recommendation is couched in terms of such general applicability. [What the warning doesn't say, though, is that the opposite problem exists too. It can be *very* hard to determine when to call 'releaseResources', a problem which carries over into the GC world too.] Also, not to be facetious, if I have a bug in my code, wouldn't I fix it? I think it's referring to the kind of bug where the object is lifetime is extended by an inscrutable chain of dependencies. If your design uses an implicit release-resource-on-dealloc pattern, it can be very hard to work out where to intervene, so the bug may be for all intents and purposes unfixable. Granted, at application tear-down, if the file is still open, it won't be closed because dealloc won't be called. But again that comes under the heading of a bug in the code. So I don't understand this injunction. Actually, at application tear-down, things like file descriptors are irrelevant, because they're destroyed automatically with your process. However, there are things with more global visibility, such as a system-wide cache, or a network login, that destruction of your process may leak. So, application tear-down tends to be the site of fewer problems, but resource management is still something that needs to be thought through. ***Actually, it may be necessary even then. *Your* application might not care if the file descriptors aren't freed until much later, but you might also be preventing other applications from gaining exclusive access to the files for some other purpose, so you'll lock out such applications possibly for hours. This is still a case of scarcity, just a different kind of scarcity. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 29, 2011, at 9:47 PM, Quincey Morris wrote: On Jun 29, 2011, at 17:43, James Merkel wrote: You should typically not manage scarce resources such as file descriptors, network connections, and buffers or caches in a dealloc method. In particular, you should not design classes so that dealloc will be invoked when you think it will be invoked. Invocation of dealloc might be delayed or sidestepped, either because of a bug or because of application tear-down. Instead, if you have a class whose instances manage scarce resources, you should design your application such that you know when you no longer need the resources and can then tell the instance to “clean up” at that point. You would typically then release the instance, and dealloc would follow, but you will not suffer additional problems if it does not. In my code I close a file in the dealloc method -- so I guess that's a file descriptor. I opened the file in the init method, so it seemed logical to close it in the dealloc method. It's only logical to close the file descriptor in dealloc if it's not a scarce resource. The word scarce is vital to this question. Here's a simple (though contrived) example. Suppose you have a loop that's compressing image files. In each iteration of the loop, you open one file for reading and create a new file from it. Let's suppose you've invented objects to represent the source and destination files, and each of these object contains a file descriptor for its open file. It's not hard to imagine, for example, that for unrelated reasons your file-reading object ends up in the autorelease pool. Thus, these objects will build up till the loop exits. If you free the file descriptor in dealloc, and you have to convert 100,000 files, you're going to need 100,000 file descriptors, because you can't recycle file descriptors because dealloc isn't being called until the end of the whole operation. That obviously isn't going to work, since the kernel can create only a very limited number of simultaneous file descriptors. In this case, the recommended solution is to give your object a 'releaseResources' method that will free up its file descriptor. This is the scenario that the above warning is talking about. Note that if scarcity isn't an issue, if there could be as many simultaneous file descriptors as you choose to create, then this pattern isn't necessary***. In real life applications, causes of deferral of dealloc can be really hard to figure out deterministically. Thus it can be hard to know whether you *need* a 'releaseResources' pattern or not. That's why the recommendation is couched in terms of such general applicability. [What the warning doesn't say, though, is that the opposite problem exists too. It can be *very* hard to determine when to call 'releaseResources', a problem which carries over into the GC world too.] Also, not to be facetious, if I have a bug in my code, wouldn't I fix it? I think it's referring to the kind of bug where the object is lifetime is extended by an inscrutable chain of dependencies. If your design uses an implicit release-resource-on-dealloc pattern, it can be very hard to work out where to intervene, so the bug may be for all intents and purposes unfixable. Granted, at application tear-down, if the file is still open, it won't be closed because dealloc won't be called. But again that comes under the heading of a bug in the code. So I don't understand this injunction. Actually, at application tear-down, things like file descriptors are irrelevant, because they're destroyed automatically with your process. However, there are things with more global visibility, such as a system-wide cache, or a network login, that destruction of your process may leak. So, application tear-down tends to be the site of fewer problems, but resource management is still something that needs to be thought through. ***Actually, it may be necessary even then. *Your* application might not care if the file descriptors aren't freed until much later, but you might also be preventing other applications from gaining exclusive access to the files for some other purpose, so you'll lock out such applications possibly for hours. This is still a case of scarcity, just a different kind of scarcity. Ok, thanks. For what I'm doing file descriptors are not a scarce resource. Also, I didn't know file descriptors are destroyed at application tear-down. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
