Re: Objects between threads
Re: Objects between threads
- Subject: Re: Objects between threads
- From: Chris Ross <email@hidden>
- Date: Mon, 9 Sep 2002 11:23:20 +0100
I just want to say thank you for all the help and advice, I realized
that
what I was doing wrong was nothing to do with threading.
I was being a dumbass newbie and not retaining things when I should
have been in any of my objects so when it came to messing around with
them all their contents had gone.
I have but one more question, I have created a custom view in Interface
Builder and it consists of a NSTextView and a NSPopUpButton. The PopUp
button sits across the top of the view and the TextView below it. When
the view is resized bigger, things are fine - I have setup the springs
correctly.
When it gets bigger then smaller it is still fine. My problem is that
if it gets
below a certain size, the TextView slides underneath the PopUpButton,
They are in a NSSplitView, and so I am wondering how to solve this
problem.
I suspect that I need to restrict the minimum size of the view, but
have no
idea how, can anyone help?
Regards,
Chris
On Monday, September 9, 2002, at 10:53 am, Jay Prince wrote:
On Sunday, September 8, 2002, at 01:44 pm, Adam Thayer wrote:
On 2002-09-08 02:07:14 -0700 Jay Prince
<email@hidden> wrote:
I carefully used two NSMutableArrays, and created a timer. The
timer causes the code getting the data to switch which arrays its
reading into, and change a variable to indicate this. Then the
thread that needs to read the data is spawned, and reads from the
array. If the timer fires before the thread is finished, the switch
doesn't happen. none of the code touches the array being read while
the thread is doing its work. This way I don't have to worry about
locks (Because I cannot have my primary thread blocked at any
point). It only writes the other only reads the flag, and based on
that, knows which array it can delete data from.
I would ask that you clarify why your main thread cannot block at any
point. I have blocked my main thread plenty of times without
affecting the performance of the thread. However, I also only lock
around non-blocking code and around as little code as possible. This
way even if thread #2 grabs the lock first, it is only in there for
1-2 lines of code, and unlocks in less than a millisecond. If you
streamline code around that lock just right, you can be in and out of
the lock before your main thread would get the CPU back anyways,
which won't affect performance one bit.
Basically, I have the producer / consumer problem. Thread number 2
needs the data and is writing it out to disk. Conceivably, this disk
write could take seconds. I cannot have thread number one blocked
for seconds, or it will loose data.
So, my work around was to have them always dealing with two different
arrays and so they never needed to talk to the same bit of memory at
the same time. The only bit of memory they both care about is the one
indicating which array to use-- which is always written by one thread
and read only by the other.
Rather than keeping the second thread around all the time, I have it
exit when its done with its chore and get restarted-- that way it
being finished tells me that I know I can switch which array the
producer is writing two, and launch it again.
This may not be the best way, or even "Wise" but it is captureing
realtime data pretty well.
_______________________________________________
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.
--
Chris Ross - email@hidden -
http://www.darkrock.co.uk
Ferite Programming Language -
http://www.ferite.org
_______________________________________________
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.