On Sun, Jun 15, 2008 at 12:03 AM, Jens Alfke [EMAIL PROTECTED] wrote
I don't think that's safe. I have seen no assurances that NSOutlineView is
thread-safe, and in general most AppKit control classes should _not_ be
accessed from background threads.
While I've been investigating this, I have
On Mon, Jun 16, 2008 at 1:25 AM, Michael Ash [EMAIL PROTECTED] wrote:
I'm not sure how having thread safe arrays would help. If you're
mutating a collection in one thread while you're accessing it from
another then you will have trouble no matter what happens.
Take this example. The outline
On Jun 16, 2008, at 7:44 AM, David wrote:
While I've been investigating this, I have found more documentation on
thread safety issues in the Threading Programming Guide. I'd read it
before but it helps to re-read. It says that NSView classes ARE thread
safe... to an extent.
Very interesting
On 15 Jun '08, at 8:05 PM, David wrote:
Threading is hard for me to comprehend in the objective-c world. In
Java,
threading is powerful and relatively simple to implement with simple
relatively consistent rules and many classes which are thread safe.
I used to be the tech lead for Java
On Jun 16, 2008, at 11:17 AM, j o a r wrote:
On Jun 16, 2008, at 7:44 AM, David wrote:
While I've been investigating this, I have found more documentation
on
thread safety issues in the Threading Programming Guide. I'd read
it
before but it helps to re-read. It says that NSView classes
On Jun 16, 2008, at 9:05 AM, Adam R. Maxwell wrote:
This level of vagueness is persistent throughout the framework docs,
though, and gives them an absolute value |v| 0 with respect to
threading (my opinion, of course). And yes, I know the file a bug
report mantra, but a) I don't get
On Jun 16, 2008, at 12:47 PM, j o a r wrote:
On Jun 16, 2008, at 9:05 AM, Adam R. Maxwell wrote:
This level of vagueness is persistent throughout the framework
docs, though, and gives them an absolute value |v| 0 with respect
to threading (my opinion, of course). And yes, I know the
On Jun 16, 2008, at 3:59 PM, Adam R. Maxwell wrote:
The confusion between thread safe and main thread only on this
list hasn't helped, either...
From a documentation perspective there is no single or simple
definition of thread safe, it all depends on the context.
Some objects are not
Thanks for the responses. I've SOLVED IT. WooHoo!
What I thought I was doing seems to be working. I am able to run a secondary
thread, adding nodes to the tree I'm displaying in the primary thread. All
problems appear to have been resolved. No need for locking or any other
magic.
I think folks
On Jun 15, 2008, at 2:36 PM, David wrote:
What I thought I was doing seems to be working. I am able to run a
secondary
thread, adding nodes to the tree I'm displaying in the primary
thread. All
problems appear to have been resolved. No need for locking or any
other
magic.
I think folks are
On Sun, Jun 15, 2008 at 8:46 PM, Bill Bumgarner [EMAIL PROTECTED] wrote:
I would highly recommend that you look long and hard at how are you are
managing the data structures that are also used by NSOutlineView. In
particular, if you are futzing with an NSMutableArray from one thread while
I'm having various intermittent problems with NSOutlineView which I can only
presume is somehow caused by my use of a secondary thread to augment the
node tree supplied via a data source.
My assumption has been that I'm not doing anything that should cause
NSOutlineView a problem. I am strictly
On 14 Jun '08, at 7:19 PM, David wrote:
I am using NSMutableArrays to hold the nodes in the tree. One thread
is
adding child nodes while the main thread maybe accessing the arrays
through
the data source. I find it hard to imagine that NSMutableArray could
be
causing the problem.
I
On Jun 14, 2008, at 7:19 PM, David wrote:
I am using NSMutableArrays to hold the nodes in the tree. One thread
is
adding child nodes while the main thread maybe accessing the arrays
through
the data source. I find it hard to imagine that NSMutableArray could
be
causing the problem.
On Jun 14, 2008, at 9:12 PM, Bill Bumgarner wrote:
As well, no amount of locking will make a non-thread-safe object
thread-safe unless you absolutely positively know that only your
code (and only your code protected by the locks) contain the only
reference to said object.
In the
15 matches
Mail list logo
