Re: Threaded data freaking out
Re: Threaded data freaking out
- Subject: Re: Threaded data freaking out
- From: publiclook <email@hidden>
- Date: Sat, 8 Mar 2003 20:06:35 -0500
One alternative is to use NSTimer instead of a separate thread. If your
goal is just to keep the user interface active while processing takes
place, using a timer to perform calculations or I/O while events are
still processed is one way to go. I find threads are usually not worth
the hassle.
Apple's overview of threaded programming is good:
http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/
ProgrammingTopics/Multithreading/index.html
Regarding books: I don't remember what I used back in the day... Those
books are dusty on the shelf or in boxes so I suppose that is not a
good sign.
"Advanced Programming in the UNIX Environment" is a good book that
includes threads.
"Programming with POSIX Threads" looks like it has potential.
Others:
"Pthreads Programming: A POSIX Standard for Better Multiprocessing"
"Posix 4: Programming for the Real World"
On Saturday, March 8, 2003, at 07:45 PM, spike wrote:
I've worked with threads to the extent that I'm using right now
before. It's only a single thread to generate the NSTableData so the
user can still quit and interact and stuffs.
The problem only happens after I run the thread the second time. If I
run the first time, it works 100% of the time. if I attempt to reload
that data, It freaks out sometimes.
I've written several multithreaded apps in the past (using Java and
REALbasic- blech) and never had any problems such as this...
Do you recommend any specific books?
...spike
On Saturday, March 8, 2003, at 09:33 am, publiclook wrote:
Multi-threaded programming and locks are not Cocoa specific. You
shouldn't attempt multi-threaded programming in any environment
without a clear understanding of the issues such as priority
inversion, deadlock, race conditions, re-entrance, etc. Correct
multi-threaded programming is very hard. You need a good book on the
subject.
On Saturday, March 8, 2003, at 04:44 AM, spike wrote:
I've been reading up on NSLock (and the related classes) and I don't
quite understand it, I did some quick stuff to test it out, but the
error still occured.
I added a property (variable?) to my class called NSLock *lock; and
in my +init class method, I lock = [[NSLock alloc] init]; and
called [lock lock] and [lock unlock] sandwiched around my modifying
code and reading code, but that didn't fix it. I don't think I was
doing it right.
in the debugger, when I got that exception, sometimes row was out of
bounds, but other times it was well within the bounds (row == 1, yet
[fileSizes count] and [fileNames count] both were 5000+.
after looking at my threads and the stackTrace and all that I
noticed that this error occurs when my [myTableView reloadData]
happens and I store that value into the BOOL.
could someone give me a quick rundown on how locking works/ how to
implement it? I read the explanation on apple's site and the thing
on cocoadevcentral's site, but I really don't understand it.
...spike
On Friday, March 7, 2003, at 07:36 pm, Cameron Hayne wrote:
Spike wrote:
I've got an app that uses NSTableView and it's threaded. I get
*** -[NSCFArray objectAtIndex:]: index (1) beyond bounds (1)
I've been using the debugger and the only 2 arrays that I'm using
I got
the data for using po and they both have like 5000 items in them
(like
they're supposed to).
The line of code that's wigging out is:
BOOL isMissing = [[fileSizes objectAtIndex: row] isKindOfClass:
[NSString class]];
Two comments:
1) You mention that your app is multi-threaded. So are you sure
that you are properly locking the data for access by the two
threads?
2) The error message seems to say that the 'row' index is 1 and
that the array 'fileSizes' has only one element in it, hence the
index is out of bounds.
Cameron Hayne
email@hidden
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.