Re: Cocoa really needs to be thread-safe
Re: Cocoa really needs to be thread-safe
- Subject: Re: Cocoa really needs to be thread-safe
- From: James DiPalma <email@hidden>
- Date: Mon, 4 Nov 2002 19:03:07 -0800
Interesting point and a long standing irritation for me.
From: Steve Klingsporn <email@hidden>
A very simple way to make this hack break down completely is to hold
down a button while events from other threads are being posted to the
main thread. NSSounds stop playing (they're played by the main
thread, apparently), events start welling up and aren't answered (main
thread is busy serving the button click, apparently), but strangely,
drawRect() gets called in your custom views.
When a button is depressed (user is holding mouseDown -- as if gravity
didn't work), NSButton blocks waiting for a mouseUp event and will also
check if the mouse leaves its bounds. I don't think NSButton must block
to provide what little functionality it provides during mouseDown:, but
NSButton always has blocked.
Many if not all of cocoa's widgets block (or simply wait for
nextEventMatchingMask:) to return a mouse-up event during mouse down.
I'm surprised anyone actually noticed. From some experience, it is more
difficult to write mouseDown: without using nextEventMatchingMask:.
When I rewrote NSFrameView's mouseDown: code,
Out of curiousity, do NSTimers fire when a button is down in a
single-threaded app? Anything that interacts with a main thread's
runloop will have difficulty functioning while a button is depressed. I
don't think its just a thread-safe issue.
I have a simple threaded application that uses detachNewThreadSelector
and NSConnections to communicate between threads. A timer in my child
thread sends [NSDate date] through a controller into a textfield. Once
started my app happily updates once a second like a digital clock. If I
depress a button, all time updates stop. If I begin a window resize,
all time updates stop. When I move this apps window, time updates work
great.
I'm not sure that "this hack" called cocoa needs to be fully thread
safe as much as it needs to fix its handling of mouseDown: and anything
else that causes a main thread's run loop to stop handling
communication with a child thread.
Even though I call display() from some of my background threads, I
notice when I poop out some results (Thread.currentThread()), that
only the main thread seems to call drawRect() in my view. Only in one
case did another thread call drawRect().
Should you be calling display() from a child thread? I think you will
get some undefined results by trying to interact with UI elements from
a child thread. Somewhere it is documented that child threads shouldn't
interact with UI elements and somewhere it is documented that calling
-display directly should be avoided.
BTW, I don't think Cocoa is re-entrant safe either. Can someone cofirm?
If so, calling -display in a child thread while a window is being
resized will likely cause problems.
-jim
_______________________________________________
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.