On 19 Feb 2009, at 18:29, Leo Singer wrote:
Sorry, I meant to send this to the list.
Leo
---------- Forwarded message ----------
From: Leo Singer <doc.aron...@gmail.com>
Date: Thu, Feb 19, 2009 at 1:28 PM
Subject: Re: Running out of memory on stack in C++ routine invoked
within Cocoa NSOperation
To: Greg Parker <gpar...@apple.com>
Thanks for all of the input on this. I decided to override
NSOperation's - start selector and make the thread myself. I wish
that there was a way to adjust the stack size per NSOperationQueue.
Maybe I should report that as a feature request.
Operation queues share and re-use threads amongst themselves, so this
almost certainly couldn't work in practice. Requesting stack size per
NSOperation seems reasonable though.
I would rather not dynamically allocate that particular array because
the Cocoa application I am developing is simply a wrapper for a cross
platform C++ project. This particular project has to manage a number
of different resources, including an SQLite database connection, an
open file, and a serial port device. In order to keep error handling
as simple as possible, I have made heavy use of the RIAA pattern. If
a serial port error occurs, for example, an exception gets thrown. As
a result, the objects representing both the database and the open file
go out of scope, and their resources are released.
A std::vector would be unsuitable also because in my actual
application (not the cooked example I sent out) I need to be able to
manipulate that memory directly.
Some more background information might be helpful. The application is
a GUI for a bootloader for Microchip brand DSPs. The big array in
question is actually a 256 kb image of the device's program memory.
Thanks again,
Leo
On Wed, Feb 18, 2009 at 3:17 PM, Greg Parker <gpar...@apple.com>
wrote:
On Feb 18, 2009, at 3:22 AM, Michael Vannorsdel wrote:
Really it would be best to malloc the space, use it, and free it.
Once
you get to huge stack usage you gamble that you won't run out when
there can
be other higher up calls also consuming some (frameworks, libs,
3rd party
code, ect). Also if you only use the large amount once in a while
then you
have a bunch of unutilized memory sitting around.
Agreed: use malloc for large memory allocations.
One other limit that you apparently haven't run into yet: some
architectures
limit the maximum size of a single stack frame, even if there is
lots of
space on the stack. ppc has a maximum 64K stack frame size; arm may
have a
similar limit.
--
Greg Parker gpar...@apple.com Runtime Wrangler
_______________________________________________
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/doc.aronnax%40gmail.com
This email sent to doc.aron...@gmail.com
_______________________________________________
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/cocoadev%40mikeabdullah.net
This email sent to cocoa...@mikeabdullah.net
_______________________________________________
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
