Re: observing dealloc
Re: observing dealloc
- Subject: Re: observing dealloc
- From: Ken Tozier <email@hidden>
- Date: Mon, 28 May 2007 19:34:51 -0400
On May 28, 2007, at 6:46 PM, Erik Buck wrote:
Your posted code is completely not thread safe. Every single
method is a threading disaster waiting to happen.
Here is a hint: If you use the words "global" or "static" or
"shared", you are going to need some form of concurrent access
protection (a mutex, semaphore, etc.).
Just scanning your code, I note that there are no bottle necks
through which gGlobals and gCounters are accessed.
Globals are fetched using globalForKey and set using
setGlobal:forKey: I made a few test subclasses and the getting/
setting is working as expected.
That is bad form in any case, but if you seriously contemplate
multi-threading, you are frankly in deep trouble.
I don't work with threads much but the globals would be almost
exclusively read only. Wouldn't that alleviate most of the threading
problem? The only real issue I can think of would be on dealloc where
I delete global sets for a class when an instance counter for that
class reaches zero.
What are you really trying to accomplish? "add globals to any
class" is a very strange goal. Why would you want to add "globals"
to any class; that doesn't even make any sense?
I found myself writing a lot of classes with properties that made
more sense to share between instances. For example, just for the sake
of argument, say that every instance of a class needed to access a
specific image. It makes more sense to put that in a global and have
instances reference it than to add an image field to every instance.
If there are thousands of instances, that's a lot of unnecessary
overhead retaining/releasing etc.
Is English your first language ?
Heh. I think so : )
Do you really mean "have global instances of any class" ?
No. I wanted a standardized way to add globals to any of my custom
classes along with a way to release these globals when all instances
of a class have been released.
- Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden