Re: Thread safety/freindlyness vs. performance (Was: Modest string handling optimisations)

[Richard Frith-Macdonald]

On 26 Aug 2004, at 10:09, David Ayers wrote:

> Richard Frith-Macdonald wrote:
>
> > On 26 Aug 2004, at 01:01, Alexander Malmberg wrote:
> >
> > > It also fails if the string is mutable. There are some other cases of
> > > this in NSString that I've been meaning to fix for a while.
> ...
> > Good point .. I consider this as more of a problem (since the memory
> > management policy issue is documented and keeps getting discussed on
> > mailing lists etc).  I guess, while it's not technically wrong to
> > return a mutable object where a method is declared as the immutable
> > version (and lots of MacOSX stuff does it), its more confusing.
>
> ...
> Yes, this should be fixed.  If the "original" mutable string is altered
> /after/ the call to -lowercaseString, this must not have an effect on
> the string returned by -lowercaseString.

I'm not 100% sure ... there are some methods (eg. 
stringByExpandingTildeInPath)
which are specifically documented as returning the receiver, so either 
we go against
the MacOS-X documented behaviors in these cases, or we don't have a 
consistent
policy :-(
MacOS-X appears to return new objects for lowercaseString (for all the 
strings I tried),
but it specifically says it doesn't to that for other methods.  I 
haven't tested, so I don't
know whether the documentation is telling the truth.
Whichever we do, we need to document it ourselves, and keep our 
documentation honest.
My inclination is to say, in the absence of a general policy, we follow 
MacOS-X behavior
and change things if they change things ... not very satisfactory, but 
it seems pragmatic.

> > Also, arguably the apple guidelines are wrong ... in a multithreaded
> > environment, even if you retain/copy immediately after receiving a
> > returned value, another thread could have destroyed it.  So it's not
> > enough to say that you should retain/copy objects immediately, and the
> > only 100% safe policy is for any method returning an object to return
> > it retained and autoreleased.  However, as most classes do not claim 
> > to
> > be thread-safe, this is perhaps not an issue.
>
> Well I'm a bit undecided about this.  Mutltithreaded apps sharing
> transient strings/arrays/dictionaries can get very complicated.  I'd 
> say
>  that *if* we add retain/autoreleased policy, we add it in an
> overridable macro.  Actually I'm currently considering doing something
> like this for gdl2 and gsweb which currently prefer autorelease by 
> policy.

I think current behavior is good in practice, as long as people are 
well aware
of the memory management guidelines.  For instance, if you do
 str = [[NSString alloc] initWithUTF8String: "AbC"];
 low = [str lowercaseString];
you *know* in practice that low is valid until you destroy str or the 
current autorelease pool.
It's only when you ask some mutable class for an object that you need 
to worry about another thread changing things ... and if you are 
writing multithreaded code you really shouldn't be sharing mutable 
objects between threads unless they claim to be thread-safe or you are 
synchronizing the threads using locks.
Having a macro to implement another policy doesn't seem like a bad 
thing though (except for a bit of additional complexity for people to 
remember), and gdl2/gsweb are so slow for other reasons that the 
performance penalty of high use of autorelease is probably not 
significant.