Re: NSThread to NSOperation and blockUntil

> On 22 Mar 2016, at 5:33 PM, Trygve Inda wrote: > > So I need to be able to have a process done in 30 seconds for example At > full speed it could be done in 4 seconds but I'd like it done with as little > impact as possible. So just let it run as fast as possible. The whole point of thre

Re: NSThread to NSOperation and blockUntil

> On Mar 22, 2016, at 2:33 AM, Trygve Inda wrote: > > So I need to be able to have a process done in 30 seconds for example At > full speed it could be done in 4 seconds but I'd like it done with as little > impact as possible. I don’t think it makes much difference to other system threads

Re: NSThread to NSOperation and blockUntil

> On Mar 21, 2016, at 18:07 , Trygve Inda wrote: >> >> I would like to move this to NSOperation and NSOperationQueue but I see no >> way to replicate this behavior. > > I think the GCD/NSOperationQueue concept of “background” quality of service is > what you want here. That would let your re-fac

Re: NSThread to NSOperation and blockUntil

On Mar 21, 2016, at 18:07 , Trygve Inda wrote: > > I would like to move this to NSOperation and NSOperationQueue but I see no > way to replicate this behavior. I think the GCD/NSOperationQueue concept of “background” quality of service is what you want here. That would let your re-factored calc

Re: [NSThread callStackSymbols] weirdness

> On Feb 3, 2016, at 11:28 PM, Trygve Inda wrote: > > why do I get to > see 3 method calls in my own app in the first example, but only the last call > in the second example? Tail-call optimization, probably. If the last thing a function does is call another function, the optimizer will chang

Re: -[NSThread start] blocks ?!?

> On 2015 Sep 28, at 13:10, Greg Parker wrote: > > The threads listed are all waiting for a spinlock used by the debugging > tools. (Specifically, it's the machinery that records stack traces of queue > operations.) > > If you see this again, please capture a spindump and file a bug report. >

Re: NSThread subclass get blocked on 'start' method call

So, the problem actually begins _before_ you create the second thread. If you look at all of the running threads, you’ll see the first thread you created (“Thread 6” on my simulator) locked up inside its dealloc method: (lldb) bt * thread #6: tid = 0x7b7198, 0x000104b4ed92 libsystem_kernel.

Re: -[NSThread start] blocks ?!?

> On Sep 26, 2015, at 3:33 PM, Jerry Krinock wrote: > > In a OS X app, predating Grand Central Dispatch, in the main thread, I create > and start a new thread > > NSThread* worker ; > worker = [[NSThread alloc] initWithTarget:instance > selector:@selector(beginW

Re: NSThread subclass get blocked on 'start' method call

On 28 сентября 2015 at 8:00:43 , Jens Alfke (j...@mooseyard.com) wrote: On Sep 28, 2015, at 9:29 AM, Alexey Belkevich wrote: Here is the source code of Example -  https://www.dropbox.com/s/r5k8o28pocu7afk/aptest.zip?dl=0 Can you isolate this down to something less complex? There’s a lot of sou

Re: NSThread subclass get blocked on 'start' method call

> On Sep 28, 2015, at 3:00 PM, cocoa-dev-requ...@lists.apple.com wrote: > > I have problem with NSThread subclass. It's very similar to this case - > http://prod.lists.apple.com/archives/cocoa-dev/2015/Sep/msg00454.html > . >

Re: NSThread subclass get blocked on 'start' method call

> On Sep 28, 2015, at 9:29 AM, Alexey Belkevich > wrote: > > Here is the source code of Example - > https://www.dropbox.com/s/r5k8o28pocu7afk/aptest.zip?dl=0 > Can you isolate this down to something less complex? There’s a lot of so

Re: -[NSThread start] blocks ?!?

> On Sep 28, 2015, at 12:13 AM, cocoa-dev-requ...@lists.apple.com > wrote: > > Thank you, John. You are referring to what my secondary thread is doing. My > point is that if we can’t at least rely on -[NSThread start] returning before > the secondary

Re: -[NSThread start] blocks ?!?

> On Sep 27, 2015, at 8:49 PM, Jerry Krinock wrote: > > My point is that if we can’t at least rely on -[NSThread start] returning > before the secondary starts, there is no way for a seconary thread to call > back to the main thread without possibility of deadlock. No, this isn't true. The on

Re: -[NSThread start] blocks ?!?

> On Sep 27, 2015, at 11:18 PM, Jens Alfke wrote: > >> On Sep 27, 2015, at 8:49 PM, Jerry Krinock > > wrote: >> >> My point is that if we can’t at least rely on -[NSThread start] returning >> before the secondary starts, there is no way for a seconary thread to call >> b

Re: -[NSThread start] blocks ?!?

—Jens > On Sep 27, 2015, at 8:49 PM, Jerry Krinock wrote: > > My point is that if we can’t at least rely on -[NSThread start] returning > before the secondary starts, there is no way for a seconary thread to call > back to the main thread without possibility of deadlock. Why? You do real

Re: -[NSThread start] blocks ?!?

On 2015 Sep 27, at 17:01, John Daniel wrote: > There is no way to tell what is causing the deadlock without knowing exactly > what is happening relating to: > 1) instance > 2) beginWithInfo: > 3) info Thank you, John. You are referring to what my secondary thread is doing. My point is that

Re: -[NSThread start] blocks ?!?

> In a OS X app, predating Grand Central Dispatch, in the main thread, I create > and start a new thread > > NSThread* worker ; > worker = [[NSThread alloc] initWithTarget:instance > selector:@selector(beginWithInfo:) > object:inf

Re: -[NSThread start] blocks ?!?

> On Sep 27, 2015, at 6:50 AM, Jerry Krinock wrote: > > I mean that if it is possible for -[NSThread start] to block indefinitely, it > is not a useable API. It’s not. The new thread will start when the kernel's scheduler gives it time. That’s technically indefinite, but realistically micros

Re: -[NSThread start] blocks ?!?

> On 2015 Sep 26, at 18:03, Quincey Morris > wrote: > > I don’t understand what you’re asking. I mean that if it is possible for -[NSThread start] to block indefinitely, it is not a useable API. I clicked the “Pause” and “Continue” multiple times in Xcode, but each time, in the main thread,

Re: -[NSThread start] blocks ?!?

On Sep 26, 2015, at 5:33 PM, Jerry Krinock wrote: > In a OS X app, predating Grand Central Dispatch, in the main thread, I create > and start a new thread > > NSThread* worker ; > worker = [[NSThread alloc] initWithTarget:instance > selector:@selector(beginWithIn

Re: -[NSThread start] blocks ?!?

On Sep 26, 2015, at 16:49 , Jerry Krinock wrote: > > By “starter thread”, I presume you mean the one which is invoking -[NSThread > start]. Yup. > If what you are saying is true, how could we ever execute > -performSelectorOnMainThread::: in a secondary thread without possibility of > deadlo

Re: -[NSThread start] blocks ?!?

> On 2015 Sep 26, at 15:53, Quincey Morris > wrote: > > On Sep 26, 2015, at 15:33 , Jerry Krinock wrote: >> >> Should not -[NSThread start] always return before running any of my code in >> the new thread? > > You have absolutely no control over it, unless you introduce your own > synchron

Re: -[NSThread start] blocks ?!?

On Sep 26, 2015, at 15:33 , Jerry Krinock wrote: > > Should not -[NSThread start] always return before running any of my code in > the new thread? You have absolutely no control over it, unless you introduce your own synchronization mechanisms. The *earliest* it can return is before the new t

Re: NSThread

I am using all this good advice to attempt to unwrap myself and the axle. I shall return. -rags > On Jan 13, 2015, at 2:09 PM, Corbin Dunn wrote: > >> >> On Jan 13, 2015, at 9:57 AM, Mike Abdullah wrote: >> >> >>> On 13 Jan 2015, at 16:18, Mike Abdullah wrote: >>> >>> On 13 Jan 2

Re: NSThread

> On Jan 13, 2015, at 9:57 AM, Mike Abdullah wrote: > > >> On 13 Jan 2015, at 16:18, Mike Abdullah wrote: >> >> >>> On 13 Jan 2015, at 16:07, Raglan T. Tiger wrote: >>> >>> I allocate and init an NSThread as follows: >>> >>> if ( m_mythread ) [m_mythread cancel]; >>> m_mythread

Re: NSThread

> On 13 Jan 2015, at 16:18, Mike Abdullah wrote: > > >> On 13 Jan 2015, at 16:07, Raglan T. Tiger wrote: >> >> I allocate and init an NSThread as follows: >> >> if ( m_mythread ) [m_mythread cancel]; >> m_mythread = [[MYThread alloc] initWithTarget:m_mythread >> selector:@select

Re: NSThread

> On 13 Jan 2015, at 17:50, Raglan T. Tiger wrote: > >> On Jan 13, 2015, at 9:18 AM, Mike Abdullah > > wrote: >> >> Step 1 of diagnosis: take a sample. > > How would that be accomplished ? A simple user-facing way is to fire up Activity Monitor, select your app,

Re: NSThread

> On Jan 13, 2015, at 9:18 AM, Mike Abdullah wrote: > > Step 1 of diagnosis: take a sample. How would that be accomplished ? -rags ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to

Re: NSThread

> On 13 Jan 2015, at 16:07, Raglan T. Tiger wrote: > > I allocate and init an NSThread as follows: > >if ( m_mythread ) [m_mythread cancel]; >m_mythread = [[MYThread alloc] initWithTarget:m_mythread > selector:@selector(start) object:m_anobject]; >[m_mythread start]; >

Re: NSThread

On Mar 8, 2011, at 12:33 AM, Bruno Causse wrote: > the performance is not a problem, all my threads are waiting for a answer to > a request. That is potentially still a big problem as every thread uses kernel resources, reserves memory for a stack, and otherwise pollutes the kernel's schedulin

Re: NSThread

the performance is not a problem, all my threads are waiting for a answer to a request. my program is a kind of working's Distributor. Le 8 mars 11 à 08:20, Bill Bumgarner a écrit : On Mar 7, 2011, at 12:27 PM, Bruno Causse wrote: hi all, how many NSThread i can create? Quite a few mo

Re: NSThread

On Mar 7, 2011, at 12:27 PM, Bruno Causse wrote: > hi all, > > how many NSThread i can create? Quite a few more than are useful, performant, or optimal... b.bum ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin reques

Re: NSThread Subclassing problem for Singleton instance

On Mon, Jul 12, 2010 at 12:33 PM, Abhinav Tyagi wrote: > Thanks for giving your valuable time to this post. > I have been working on Mac platform since last 5 months prior to which I have > worked on Windows platform. > I have used threads using  NSThread's > detachNewThreadSelector:@selector() ea

Re: NSThread Crashes on Intel

Tried that and still crashes. Here is the crash report if it helps Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0xc023 Crashed Thread: 1 Thread 0: 0 libSystem.B.dylib 0x967414a6 mach_msg_trap + 10 1 libSystem.B.dylib

Re: NSThread and UI

On Jul 20, 2008, at 2:01 PM, Torsten Curdt wrote: So in the following naive code I would have to either wrap the calls to the progressIndicator object through a performSelectorOnMainThread or could send NSNotifications to update it on the main thread. Notifications — whether via NSNotific

Re: NSThread and UI

On Jul 20, 2008, at 4:01 PM, Torsten Curdt wrote: AFAIU accessing UI elements from within an NSThread is a big no-no. There are exceptions, but that's a good rule of thumb. Here are Apple's specific guidelines: http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/ThreadSaf

Re: NSThread and UI

AppKit stuff isn't thread safe. AppKit stuff is usually the user interface stuff (like Progress bars) So that should be run on the main thread, something like: > [NSThread detachNewThreadSelector:@selector(convert) > toTarget:self > withObject

Re: NSThread, NSAutoreleasePool and mach_trap_msg

On Jun 18, 2008, at 11:10 AM, Georg Schuster wrote: I'm sorry that I can't post any real code, but does anybody know if there are some special things I should keep an eye on when programming the WorkerClass? I tried to read every doc about threads and autoreleasepools I could get my hands on