all,
A user reported our app froze and had to be force quit, and provided this
trace from the crash report.
It looks to me to be a classic thread deadlock in the bowels of the kernel -
can anyone comment? Is there anything we can do about this sort of thing, or
just file a bug and hope
On 2012 May 16, at 02:23, Matt Gough wrote:
Graham,
I have seen similar hangs in other apps while trying to access recent items
menu.
On my Mac I put it down to occasional disk freezing issues quite common on
the model of disk I am using, but maybe its software related after all.
Me
Hi all,
A user reported our app froze and had to be force quit, and provided this
trace from the crash report.
It looks to me to be a classic thread deadlock in the bowels of the kernel -
can anyone comment? Is there anything we can do about this sort of thing, or
just file a bug and hope
froze and had to be force quit, and provided this
trace from the crash report.
It looks to me to be a classic thread deadlock in the bowels of the kernel -
can anyone comment? Is there anything we can do about this sort of thing, or
just file a bug and hope?
--Graham
Report
In the middle of the thread processing, I need to do some processing on a
downloaded file. The file may be in the middle of being downloaded, so I
need to possibly block until it is ready, then have the main thread do some
work, and return to the thread.
Which thread is doing the download?
I am seeing a deadlock I think... It works in the debugger, but hangs when
running alone. The killThread is called as part of the
applicationWillTerminate delegate method.
My thought is that somehow after blocking to wait for kConditionThreadIdle,
my performSelectorOnMainThread is getting called.
On Mon, Aug 11, 2008 at 8:09 AM, Trygve Inda [EMAIL PROTECTED] wrote:
I am seeing a deadlock I think... It works in the debugger, but hangs when
running alone. The killThread is called as part of the
applicationWillTerminate delegate method.
You can use gdb to attach to the program after it
Date: Mon, 11 Aug 2008 12:09:05 +
From: Trygve Inda [EMAIL PROTECTED]
I am seeing a deadlock I think... It works in the debugger, but
hangs when
running alone. The killThread is called as part of the
applicationWillTerminate delegate method.
My thought is that somehow after blocking to
...but it would surprise if you have to take the lock
just to inspect the condition (per the threadMustExit method).
That part is correct, as it's the entire point behind conditions, atomically
check a condition and release the lock at the same time (and subsequently
relock)--in order to avoid
Key Trygve,
This looks similar to the threading code we talked about a while
back. Far be it for me to say that my threading code is bugless :),
but I haven't run into a deadlock problem, and the code you posted
has two changes that would give me pause...
[self
Date: Mon, 11 Aug 2008 12:29:55 -0600
From: Scott Ribe [EMAIL PROTECTED]
...but it would surprise if you have to take the lock
just to inspect the condition (per the threadMustExit method).
That part is correct, as it's the entire point behind conditions,
atomically
check a condition and
Which part is correct? The original code?
The original code was what I meant. However I was thinking of traditional
conditions locks; NSConditionLock does operate at a higher level, and you
are right that there is no need for an unconditional lock. But really, I
don't see a need for a lock at
Which part is correct? The original code?
The original code was what I meant. However I was thinking of traditional
conditions locks; NSConditionLock does operate at a higher level, and you
are right that there is no need for an unconditional lock. But really, I
don't see a need for a
Which blocks until the method completes, so I need a way to end the thread,
but in the original code the killThread method blocks waiting for the thread
to finish.
I probably need to launch a timer or other notification system when the
thread finishes.
Why?
--
Scott Ribe
[EMAIL
There is a chance that my calls to performSelectorOnMainThread can have
waitUntilDone:NO
I use [myNSData writeToFile:path atomically:YES]
NSFileHandle and NSFileManager are shown as not thread safe, but NSData
is... Perhaps it is ok, but I would think NSData uses one or both of the
above.
One
There is a chance that my calls to performSelectorOnMainThread can have
waitUntilDone:NO
I use [myNSData writeToFile:path atomically:YES]
NSFileHandle and NSFileManager are shown as not thread safe, but NSData
is... Perhaps it is ok, but I would think NSData uses one or both of the
There is a chance that my calls to performSelectorOnMainThread can have
waitUntilDone:NO
I use [myNSData writeToFile:path atomically:YES]
NSFileHandle and NSFileManager are shown as not thread safe, but NSData
is... Perhaps it is ok, but I would think NSData uses one or both of the
Date: Mon, 11 Aug 2008 21:15:27 +
From: Trygve Inda [EMAIL PROTECTED]
The real issue here is that I need to use
[self performSelectorOnMainThread:@selector(doUnsafeStuff)
withObject:nil waitUntilDone:YES];
Which blocks until the method completes, so I need a way to end the
On Mon, Aug 11, 2008 at 5:15 PM, Trygve Inda [EMAIL PROTECTED] wrote:
Which part is correct? The original code?
The original code was what I meant. However I was thinking of traditional
conditions locks; NSConditionLock does operate at a higher level, and you
are right that there is no need
19 matches
Mail list logo
