Re: NSTableDataSources and multi-threading
Re: NSTableDataSources and multi-threading
- Subject: Re: NSTableDataSources and multi-threading
- From: Sean Gilbertson <email@hidden>
- Date: Thu, 6 Nov 2003 02:05:02 -0600
Guys,
Man, I didn't even notice this thread was replied to, until just now.
I have Mail on threaded mode, and I was sifting through it almost
belligerently, looking for responses. Anyway, I'm here now.
Nick, Shawn is correct. Your approach is what I attempted at first
(and indeed, left the code in an alpha release of my software).
>
As it stands I don't think a way exists for the data source
>
(controller) to know what is needed without subclassing of
>
NSTableView.
I actually did this! Overriding reloadData is not sufficient,
however, and there are ostensibly many places I'd have to overload or
redefine behavior, even to an unreliable degree. I found some source
code for NSTableView on the web (from some NextStep reference, or
something), and looked through it, and you've probably noticed that
reloadData is not the only time a table view updates: if the view is
hidden or resized, numberOfRows and objectValue are called. I wish
there were some "bottleneck" method that NSTableView had, which all
requests for the number of rows and object value went through. There
is indeed what seems to be a "bottleneck" function for objectValue (see
attached source at "_objectValueForTableColumn:row:"), but I believe it
to be deceptive.
I was discouraged by these issues, because making my own tableView
would be ideal (I could "notify" the data source before a query), and
now that I think about it.. I wonder if noteNumberOfRowsChanged and
_objectValueForTableColumn:row: may indeed be bottleneck methods?
maybe I should test this more.
>
Sean, are your threads inserting and/or removing rows? If they are
>
only appending rows to the data source then you should not have an
>
issue, just use noteNumberOfRowsChanged.
The data being represented is a download queue, so all the cells may
change, and rows are deleted all the time, sometimes many rows in
succession (imagine this: a handful of downloads error-ing immediately:
they would change between the wait queue, the download queue, and the
error queue in a matter of milliseconds.).
>
Otherwise I would consider modifying your data source on the main
>
thread only (possibly in bursts, queuing in your background threads a
>
little). This will insure that your view isn't updating at the same
>
time that your data source is changing. Look at using NSObject's
>
performSelectorOnMainThread.
I was looking through the documentation for this method. The main
thread does all the UI work, right?? That would work -- it's dirty,
but it will work. I only hope I don't catch the main thread in between
calls. Is that possible? I would hope that Cocoa would be intelligent
enough to avoid that, but who knows?
Thank you both very much for your input! Again, sorry for the delayed
response.
- Sean
On Nov 5, 2003, at 12:11 AM, Shawn Erickson wrote:
>
>
On Nov 4, 2003, at 8:43 PM, Nick Zitzmann wrote:
>
>
> On Nov 4, 2003, at 12:11 AM, Sean Gilbertson wrote:
>
>
>
>> I have a data source, whose represented data is updated by several
>
>> threads. Because of this, the result of numberOfRowsInTableView:
>
>> may not be valid by the time
>
>> tableView:objectValueForTableColumn:row: is called. I have tried
>
>> several ways of making sure that this does not occur, including
>
>> subclassing NSTableView and notifying the data source when
>
>> reloadData is called, but of course that is not the appropriate
>
>> place to look for redrawing of the table view; it is an auxiliary
>
>> method. Of course, I am using locks, but they are almost worthless
>
>> unless I can actually guarantee incorrupt output.
>
>
>
> The way I fixed this with one project was to add a lock object, use
>
> PB's Find window to point out each place in the code that the data
>
> source was being accessed, and then add balancing lock and unlock
>
> calls to each place. It's pretty much the only way to do what you
>
> want to do...
>
>
Nick, if I understand what you as saying above the locking you are
>
suggesting is to granular and will not avoid the issue Sean is talking
>
about. What is needed is a way to insure that the data source isn't
>
updated while table data is being reloaded by the table view. I assume
>
Sean is worried about being asked about a row that doesn't exist any
>
longer.
>
>
As it stands I don't think a way exists for the data source
>
(controller) to know what is needed without subclassing of
>
NSTableView.
>
>
Sean, are your threads inserting and/or removing rows? If they are
>
only appending rows to the data source then you should not have an
>
issue, just use noteNumberOfRowsChanged.
>
>
Otherwise I would consider modifying your data source on the main
>
thread only (possibly in bursts, queuing in your background threads a
>
little). This will insure that your view isn't updating at the same
>
time that your data source is changing. Look at using NSObject's
>
performSelectorOnMainThread.
>
>
-Shawn
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.