Re: Main Thread UI and Detached Thread

FROM : Mike
DATE : Mon Mar 31 21:25:33 2008

Hank Heijink (Mailinglists) wrote:
>
> 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.

>
> The issue wouldn't be the main thread being too slow, but the worker
> thread being too fast, as it were. You'd be surprised how often you can
> be wrong with this kind of stuff. I've wasted hours thinking "It surely
> can't be x" and then actually measuring and finding it was x all the
> time. How big is the bunch of objects your program needs to delete? How
> long does it take to delete one item?


It could be anywhere from 1 to an unlimited number of items. I have no
idea how long it takes to delete each one and I don't have time to play
around with performance tools.

>> 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.

>
> If you change the UI values with setNeedsDisplay: calls, they only get
> updated once in every iteration of the main run loop. If there's a lot
> going on on that run loop, you may see just one value change (the last
> one) or none at all if you reset the values when you're done. If you're
> using bindings I'm not sure about the timing, but it's definitely not
> going to be faster than direct calls.


I am doing nothing in the main run loop when th worker thread fires. The
main thread is doing nothing but idling and this isn't a case of seeing
intermittent things change - NOTHING ever gets updates while the worker
is running. I don't really care about speed. Fast or slow doesn't
matter. What I want is to see the items update while the worker is
running, not after it's done. If I wanted nothing to happen until after
the operation was done, then I would just abandon threads altogether and
just call a single method on the main thread on completion.

> Have you measured how long it takes for your worker thread to complete
> its task? If it's less than a second, I'm not sure if you need a
> progress bar at all. A progress bar combined with changing  text doesn't
> make a lot of sense if that updates faster than your user can read
> anyway, so you might want to tone down the update speed.


Well, it could be fast on a Mac Pro but very slow on a PowerBook G4 400.
It could be fast because only one item is being deleted, or it could be
very slow because 1,000,000 items are being deleted. The point is: I
shouldn't have to care. It should just do the right thing and update
when I tell it to.

> Hank
>

>> 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/hank.<email_removed>
>>
>> This email sent to hank.<email_removed>
>>

>
>