FROM : Mike
DATE : Mon Mar 31 21:28:35 2008
Matt Mashyna wrote:
> As long as we're top posting...
>
> Why not update values for your worker thread and spawn another thread
> that does the UI progress updates periodically ? Works nice for me. I
> update the UI with whatever my controller object's state is at that
> moment and then sleep for a little. I like this scheme because I can let
> my worker thread run full-tilt and tweak the progress thread if I need to.
>
> Matt
>
But my question is: why should I have to?
The docs say run all the UI on the main thread and notify
the main thread from within the worker thread when the UI needs updating.
Now you're saying I have to spawn yet another thread to do what the docs
say the main thread should be doing? Why do I have to use an
overly-elaborate
design for something Apple says I shouldn't have to? Is Apple lying in
the docs?
Mike
> On Mar 31, 2008, at 2:06 PM, Mike wrote:
>
>> I suppose it's possible. The spawned thread does a lot of setup then
>> iterates some arrays of a bunch of objects in the filesystem that it
>> needs to delete. The idea is to update the progress bar one increment
>> with each item being deleted. I'm using a MacBook 2.16 Ghz but I doubt
>> that the main thread is too slow to be able to do the updates.
>>
>> Also, I set a message text item with the name of each item being
>> deleted in the window as the worker thread runs. I never see it change
>> even for an instant. I find it hard to believe that there can't be any
>> visual update no matter how quickly the worker thread completes.
>>
>> Hank Heijink (Mailinglists) wrote:
>>> Just checking the obvious here - is it possible that your worker
>>> thread completes its work so fast that the main run loop hasn't
>>> updated the screen once before it's done? Keep in mind that the main
>>> thread has to display your window with the progress bar and the text
>>> and (depending on your implementation) that your worker thread may be
>>> working (and completing) while that's being done.
>>> On Mar 30, 2008, at 2:55 PM, Mike wrote:
>>>> I have all my UI running on my app's main thread. I have a worker
>>>> thread that I detach with
>>>> detachNewThreadSelector:toTarget:withObject: (my worker thread).
>>>>
>>>> In my worker thread I do a tight processing loop and one of the
>>>> things I do in the loop is call two methods in the main thread to
>>>> update the display (a text message and progress bar) - via
>>>> performSelectorOnMainThread:withObject:waitUntilDone:modes.
>>>>
>>>> However, when the loop runs in the spawned thread, the display
>>>> doesn't get updated. If I insert a sleep(1) call into the loop, then
>>>> the display updates.
>>>>
>>>> Why doesn't the main thread process the changes to the UI unless I
>>>> call sleep? I thought the whole idea of using a separate thread was
>>>> so that the main thread could continue to run on its own?
>>>>
>>>> Thanks,
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> Cocoa-dev mailing list (<email_removed>)
>>>>
>>>> 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:
>>>> http://lists.apple.com/mailman/options/cocoa-dev/hank.<email_removed>
>>>>
>>>> This email sent to hank.<email_removed>
>>>>
>> _______________________________________________
>
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
>
> This email sent to <email_removed>
>
DATE : Mon Mar 31 21:28:35 2008
Matt Mashyna wrote:
> As long as we're top posting...
>
> Why not update values for your worker thread and spawn another thread
> that does the UI progress updates periodically ? Works nice for me. I
> update the UI with whatever my controller object's state is at that
> moment and then sleep for a little. I like this scheme because I can let
> my worker thread run full-tilt and tweak the progress thread if I need to.
>
> Matt
>
But my question is: why should I have to?
The docs say run all the UI on the main thread and notify
the main thread from within the worker thread when the UI needs updating.
Now you're saying I have to spawn yet another thread to do what the docs
say the main thread should be doing? Why do I have to use an
overly-elaborate
design for something Apple says I shouldn't have to? Is Apple lying in
the docs?
Mike
> On Mar 31, 2008, at 2:06 PM, Mike wrote:
>
>> I suppose it's possible. The spawned thread does a lot of setup then
>> iterates some arrays of a bunch of objects in the filesystem that it
>> needs to delete. The idea is to update the progress bar one increment
>> with each item being deleted. I'm using a MacBook 2.16 Ghz but I doubt
>> that the main thread is too slow to be able to do the updates.
>>
>> Also, I set a message text item with the name of each item being
>> deleted in the window as the worker thread runs. I never see it change
>> even for an instant. I find it hard to believe that there can't be any
>> visual update no matter how quickly the worker thread completes.
>>
>> Hank Heijink (Mailinglists) wrote:
>>> Just checking the obvious here - is it possible that your worker
>>> thread completes its work so fast that the main run loop hasn't
>>> updated the screen once before it's done? Keep in mind that the main
>>> thread has to display your window with the progress bar and the text
>>> and (depending on your implementation) that your worker thread may be
>>> working (and completing) while that's being done.
>>> On Mar 30, 2008, at 2:55 PM, Mike wrote:
>>>> I have all my UI running on my app's main thread. I have a worker
>>>> thread that I detach with
>>>> detachNewThreadSelector:toTarget:withObject: (my worker thread).
>>>>
>>>> In my worker thread I do a tight processing loop and one of the
>>>> things I do in the loop is call two methods in the main thread to
>>>> update the display (a text message and progress bar) - via
>>>> performSelectorOnMainThread:withObject:waitUntilDone:modes.
>>>>
>>>> However, when the loop runs in the spawned thread, the display
>>>> doesn't get updated. If I insert a sleep(1) call into the loop, then
>>>> the display updates.
>>>>
>>>> Why doesn't the main thread process the changes to the UI unless I
>>>> call sleep? I thought the whole idea of using a separate thread was
>>>> so that the main thread could continue to run on its own?
>>>>
>>>> Thanks,
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> Cocoa-dev mailing list (<email_removed>)
>>>>
>>>> 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:
>>>> http://lists.apple.com/mailman/options/cocoa-dev/hank.<email_removed>
>>>>
>>>> This email sent to hank.<email_removed>
>>>>
>> _______________________________________________
>
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
>
> This email sent to <email_removed>
>






Cocoa mail archive

