RE: using autorelease in apple's CF
Subject: Re: using autorelease in apple's CF
From: thera...@sucs.org
Date: Wed, 13 May 2015 08:52:35 +0100
CC: i...@vucica.net; lu...@dolezel.info; gnustep-dev@gnu.org
To: alexey.pereva...@hotmail.com
On 13 May 2015, at 07:25, Alexey Perevalov alexey.pereva...@hotmail.com
wrote:
right now it's more clear, I think, due CF function is not automatically
put bridged(or not) objects into autorelease pool, e.g.
CFStreamCreatePairWithSocket,
client should release it manually, like in
https://github.com/robbiehanson/CocoaAsyncSocket/blob/master/GCD/GCDAsyncSocket.m
with readStream/writeStream.
There are some grey areas. Apple has now marked up most (all?) of their CF
APIs with ARC-compatible annotations indicating ownership transfer, so if
you use CF APIs from an Objective-C compilation unit compiled with ARC then
you don't need to worry about memory management - ARC will handle it for
you. I don't believe that these annotations have made it into GNUstep's
CoreBase (CF implementation).
If I truly understand, to place object into autorelease pool need to send
autorelease message [object autorelease], it will release ownership from client
code,
in details, it just send addObject of AutoreleasePool instance, it puts object
into pool.
In my implementation, for example of CFString,
CFStringRef CFStringCreateWithCString(CFAllocatorRef allocator, const char
*cString, CFStringEncoding encoding){
return ToCFString([[NSString allocWithZone:NULL] initWithCString:cString
encoding:convertCFEncodingToNSEncoding(encoding)]);
}
Just NSString is created, and initWithCString is not calling autorelase, but
stringWithCString is calling it.
So if in CFStringCreateWithCString just send autorelease for newly created
object, no need to warry about releasing it in client code,
in case of client is ARC enabled.
David
-- Sent from my brain
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: using autorelease in apple's CF
On 13 May 2015, at 09:39, Alexey Perevalov alexey.pereva...@hotmail.com wrote:
If I truly understand, to place object into autorelease pool need to send
autorelease message [object autorelease], it will release ownership from
client code,
in details, it just send addObject of AutoreleasePool instance, it puts
object into pool.
In my implementation, for example of CFString,
CFStringRef CFStringCreateWithCString(CFAllocatorRef allocator, const char
*cString, CFStringEncoding encoding){
return ToCFString([[NSString allocWithZone:NULL] initWithCString:cString
encoding:convertCFEncodingToNSEncoding(encoding)]);
}
Just NSString is created, and initWithCString is not calling autorelase, but
stringWithCString is calling it.
So if in CFStringCreateWithCString just send autorelease for newly created
object, no need to warry about releasing it in client code,
in case of client is ARC enabled.
I don’t think I understand the last bit. Autoreleasing something means ‘I have
a temporary reference to this, which I intend to pass up the stack, and it
should be deleted at some point in the future’. You trade not having to
release it in the calling code for having to retain it in the calling code if
it does want to retain a reference to the object.
Autoreleasing is also slower than releasing because it requires adding the
object to the pool and then popping it later. It’s also not great for memory
consumption, because the object will be kept alive by the reference owned by
the autorelease pool, right until the point at which it is deleted.
This is why, in ARC mode, the compiler has the option of promoting a returned
autoreleased object to a retained object and then explicitly releasing it.
The main reason to use autoreleased references is if you expect to have a lot
of assignments of that reference to temporaries as the reference is propagated
up the stack. These won’t need retain count manipulations.
In pre-ARC Objective-C, autorelease was also a good way of returning temporary
objects, as the caller didn’t need to free them. With ARC, the compiler will
do the same thing more efficiently (and reduce overall memory usage).
What problem are you actually trying to solve?
David
-- Sent from my brain
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep core release
On 12 May 2015, at 22:35, Riccardo Mottola riccardo.mott...@libero.it wrote: Hi, Fred Kiefer wrote: Richard and I are planing to do a shared release of the GNUstep core modules (at least base, gui, back, maybe make as well) on May 15th. Could you all please test the current code and report any regressions. Up to this date we should all stop to add new features and restrict us to important bug fixes. I would like to see certain bugs fixed or at least analyzed before a release 1) bug #45032: [base] Bundle not correctly returned for Class in Framework which I'd classify as a blocker As long as this is ony on your Solaris system, it's hard to see how to address it (unless you can provide a fix). Is it a regression, or a long term problem? 2) bug #45081: gui and back do not pick up compiler setting Confirm my fix and agree if have a warning or error like now I think your fix looks fine, and for the case where an environment variable is used explicitly, I think a warning is sufficient (I'm a power user and am OK with the error; since it only takes 30 seconds to reconfigure/reinstall gnustep-make for a new compiler, but if it really bugs someone else then I don't mind it being a warnign instead). 3) bug #43454: Problem with Continuous Spell Checking How serious is this? I'm not familiar with that one ... will try to take a look at it today. 4) bug #29730: Build attempt when typing 'make distclean' twice I'll definitely get that into base. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: using autorelease in apple's CF
Hello Ivan and Luboš, thank you for clarification, right now it's more clear, I think, due CF function is not automatically put bridged(or not) objects into autorelease pool, e.g. CFStreamCreatePairWithSocket, client should release it manually, like in https://github.com/robbiehanson/CocoaAsyncSocket/blob/master/GCD/GCDAsyncSocket.m with readStream/writeStream. BR, Alexey From: i...@vucica.net Date: Tue, 12 May 2015 21:50:35 +0100 Subject: Re: using autorelease in apple's CF To: lu...@dolezel.info CC: gnustep-dev@gnu.org Alexey, To further clarify:- Core Foundation: base libraries exposing a C API that implement strings, arrays, etc. Some free software/open source implementations: Apple's implementation, GNUstep's corebase- Foundation: base libraries exposing an Objective-C API that implement strings, arrays, etc.. Some free software/open source implementations: Apple's implementation, GNUstep's base, Cocotron- You can add (generally) add Core Foundation objects into Foundation's autorelease pool, and (mostly) send them certain Objective-C messages; that is, they pretend to be/are Objective-C objects- objc_autorelease, based on its name, would exist in the Objective-C runtime (e.g. libobjc2), and it doesn't. - objc_release is provided by the runtime for the sake of ARC, not because it is strictly necessary for an implementation of Foundation written in Objective-C. HTH On Tue, May 12, 2015 at 9:34 AM, Luboš Doležel lu...@dolezel.info wrote: On 05/12/2015 09:34 AM, Alexey Perevalov wrote: Hello gnustep developers! I'm interesting in using autorelease pool from apple's CF (http://www.opensource.apple.com/source/CF/, http://www.opensource.apple.com/source/CFNetwork/). In gnustep implementation autorelease message ([(object) autorelease]) for allocated object is sending. I'm talking about svn.gna.org/svn/gnustep/libs/base/trunk, whole implementation was made on objective C. But CF published on opensource.apple.com written on C. So the question how they are putting objects into autorelease pool? My assumption, somewhere should be objc_autorelease invocation, but where? BR Alexey You're confusing things. CF doesn't have any functions for autoreleasing. You can only autorelease via Foundation, which was never open sourced by Apple. -- Luboš Doležel ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep core release
Am 13.05.2015 um 08:09 schrieb Richard Frith-Macdonald richardfrithmacdon...@gmail.com: On 12 May 2015, at 22:35, Riccardo Mottola riccardo.mott...@libero.it wrote: Fred Kiefer wrote: Richard and I are planing to do a shared release of the GNUstep core modules (at least base, gui, back, maybe make as well) on May 15th. Could you all please test the current code and report any regressions. Up to this date we should all stop to add new features and restrict us to important bug fixes. I would like to see certain bugs fixed or at least analyzed before a release It would be great to resolve all these, but none of it is a show stopper. The release should be done regardless of the state of these bugs. 1) bug #45032: [base] Bundle not correctly returned for Class in Framework which I'd classify as a blocker As long as this is ony on your Solaris system, it's hard to see how to address it (unless you can provide a fix). Is it a regression, or a long term problem? As far as I know this is no regression. It seems to be related to NSBundle having a wrong view of the file system layout. Sometimes only the first number from the version gets used. Most likely this only affects Solaris as we use different mechanisms on other systems to get the classes when loading a framework. A simple solution could be to check for different directories, removing the parts of the version number one by one. 2) bug #45081: gui and back do not pick up compiler setting Confirm my fix and agree if have a warning or error like now I think your fix looks fine, and for the case where an environment variable is used explicitly, I think a warning is sufficient (I'm a power user and am OK with the error; since it only takes 30 seconds to reconfigure/reinstall gnustep-make for a new compiler, but if it really bugs someone else then I don't mind it being a warnign instead). I would prefer to have this as a warning in gui and back. On the other hand I personally never had the need to use a special compiler for building these. 3) bug #43454: Problem with Continuous Spell Checking How serious is this? I'm not familiar with that one ... will try to take a look at it today. This issue is annoying but hard to resolve. Waiting for this might delay the release indefinitely. Do we really want to do this? There are two issues here. One being that the layout system isn't thread safe. To change this requires a lot of rework. The other is, why are we getting there? To reproduce the problem I had to write illegal code. Which part of gui is accessing the layout system from a secondary thread? It might be easier to address this. 4) bug #29730: Build attempt when typing 'make distclean' twice I'll definitely get that into base. This is a rather old issue, it would be nice to have it fixed, but again not needed for a release. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: using autorelease in apple's CF
On 13 May 2015, at 07:25, Alexey Perevalov alexey.pereva...@hotmail.com wrote: right now it's more clear, I think, due CF function is not automatically put bridged(or not) objects into autorelease pool, e.g. CFStreamCreatePairWithSocket, client should release it manually, like in https://github.com/robbiehanson/CocoaAsyncSocket/blob/master/GCD/GCDAsyncSocket.m with readStream/writeStream. There are some grey areas. Apple has now marked up most (all?) of their CF APIs with ARC-compatible annotations indicating ownership transfer, so if you use CF APIs from an Objective-C compilation unit compiled with ARC then you don’t need to worry about memory management - ARC will handle it for you. I don’t believe that these annotations have made it into GNUstep’s CoreBase (CF implementation). David -- Sent from my brain ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
