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
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
roze" 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?
>
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 bu
> 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?
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 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
thr
>> 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
> 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
above.
One of
> 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 PROT
>> 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 fo
> 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
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
> 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 per
> ...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 avo
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
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 i
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.
19 matches
Mail list logo
