Re: Race in Apple's NSTreeContoller/NSOutlineView
Re: Race in Apple's NSTreeContoller/NSOutlineView
- Subject: Re: Race in Apple's NSTreeContoller/NSOutlineView
- From: Ron Lue-Sang <email@hidden>
- Date: Fri, 15 Aug 2008 20:40:16 -0700
Hey Godfrey,
I just happened upon this email. Could you please file a bug and
include a sample project?
On Jun 21, 2008, at 12:44 AM, Godfrey van der Linden wrote:
Ok I gave up. No response was expected and I received what I
expected.
I suspect, but can't prove it, that there is a subtle race in the
NSTreeContoller's bindings when the view that it is defined is is
loaded late by programtically adding its outline view as a sub view
of some container view. I ran my program twice and a differnt
outline view populated both times.
I no longer trust the treecontroller/outlineview bindings, they
appear to be broken on multi-cpu machines, even though my client
code does not have any explicit threads launched.
As I really needed filtering I decided that I may as well roll my
own data source for the outline view. Is the NSTreeController
really ready for primetime with CoreData on an MP box?
Godfrey van der Linden
On 2008-06-20, at 12:49 , Godfrey van der Linden wrote:
Ok, this bug is thread related. I suspected that this was the case
earlier since the problem is non-deterministic. Now I'm pretty sure.
The bug I have specified below DOES NOT OCCUR on a powerbook. Now
combining non-determinism with only occurring on an iMac CoreDuo.
I'm not much of a user land programmer yet but my 10 years of
kernel experience says that somebody got a lock wrong somewhere.
Are there any engineers out there interested in tracking this
down? If not I'm probably not going to bother to write up a bug
report due to a total lack of interest.
Godfrey van der Linden
On 2008-06-20, at 8:13 AM, Godfrey van der Linden wrote:
This is a resend of the previous email with a more accurate title
and better organised detail.
This bug is blowing my mind as the behaviour is not deterministic.
I have three outline views that are contained in 2 different
NSViewControlled sub-xibs which get loaded into the a place holder
view in the main persistent document window. The outlines views
are only *occasionally* updated when new data is loaded into their
NSTreeControllers.
Failed attempts to localise the bug:-
1> Call reloadData many times from many different places.
2> In primary document xib add a debug window which displays the
contents of the managed object context using parallel tree
controller and outline views, the debug window is updated fine.
3> In primary document xib, replace NSViewController architecture
with direct outline views connected to the debug window's tree
controller. Both the debug window and the direct outline views
updated.
4> Bind the sub-xibs outline view to the primary document window's
tree controllers. Debug window updates correctly but sub-xibs
outline views don't!
The sub-xib bindings are through the NSViewControllers
representedObject, which gets set not at awakeFromNib time but
later when the subview is activated.
Finally the non deterministic behaviour is that rarely one of the
two outline views, thought not always the same one, does get data
updates and once that happens that outline view seems fine thought
the other one still has no data.
So far I haven't tested the code on a single processor machine. My
code, however, does not explicitly launch any threads.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden