Re: Exact semantics of NSThread executation states?

[Glenn L. Austin]

> On Jul 12, 2016, at 2:52 PM, Sean McBride  wrote:
> 
> Hi all,
> 
> NSThread has at least 3 execution state properties: executing, finished, 
> cancelled.  Alas, the docs don't say much about what they mean beyond 
> circular definitions like "A Boolean value that indicates whether the 
> receiver is executing".
> 
> I have code where I create an NSThread, add a runloop source, then invoke 
> "start" on the thread.  I have assumed that once I invoke "start" that 
> "isExecuting" should give YES.  Literally:
> 
>   [myThread start];
>   assert([myThread isExecuting]);
> 
> On 10.11.5 and earlier this *seems* to always be true, but on 10.12b2 it's 
> not.  I'm trying to understand if my assumption was wrong or if it's an OS 
> bug.

There's no guarantee that a thread will be running at exit of -[NSThread start] 
-- only that it has been scheduled for execution. The lower-level pthread APIs 
also don't guarantee that the thread will start executing when the thread is 
created.

In reality, there's a fourth state -- scheduled -- that comes before executing. 
 Most of the time you don't need to worry about it.

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><
<http://www.austinsoft.com>


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Exact semantics of NSThread executation states?

[Sean McBride]

Hi all,

NSThread has at least 3 execution state properties: executing, finished, 
cancelled.  Alas, the docs don't say much about what they mean beyond circular 
definitions like "A Boolean value that indicates whether the receiver is 
executing".

I have code where I create an NSThread, add a runloop source, then invoke 
"start" on the thread.  I have assumed that once I invoke "start" that 
"isExecuting" should give YES.  Literally:

[myThread start];
assert([myThread isExecuting]);

On 10.11.5 and earlier this *seems* to always be true, but on 10.12b2 it's not. 
 I'm trying to understand if my assumption was wrong or if it's an OS bug.

Thanks,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSThread to NSOperation and blockUntil

[Graham Cox]

> 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 threads is to let 
them work as hard as they need to and the scheduler will take care of giving 
other stuff the time they need. If the work is self-contained, in that it isn’t 
blocking other code, you won’t even notice it. It sounds like you’re trying to 
optimise based on faulty reasoning.

—Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSThread to NSOperation and blockUntil

[Jens Alfke]

> 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 whether your 
thread takes 4 seconds or 30 to complete. Modern computers are almost never 
starved for CPU resources since they have a lot of cores and the OS is very 
good at fast context switching. On my MBP the only time the CPU meter fills up 
all the way is when Xcode is doing a clean build of a project, and even then I 
don’t notice other apps slowing down.

If you’re really worried, you can use that background quality-of-service level 
on your thread/queue, and the OS will just put your thread on ice while other 
threads are contending for all the CPU cores.

The resources that are more often limited are RAM and I/O. So it makes _much_ 
more of a difference to the rest of the system if your task uses a lot of 
memory or reads/writes a lot of data. In that case it could be advantageous to 
slow it down artificially, although you might get more bang for the buck by 
trying to optimize the algorithms to use less memory or I/O.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSThread to NSOperation and blockUntil

[Trygve Inda]

> 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 calculations run at full
> speed during system idle times, using multiple CPUs, until CPU resources were
> needed for something of higher quality service. At that time, your background
> calculation would be throttled back until the system goes idle again.

That is a possibility, but I still need to have the process done by a set
time (unless it simply can't do it all even at 100%).

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.





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSThread to NSOperation and blockUntil

[Quincey Morris]

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 calculations run at full 
speed during system idle times, using multiple CPUs, until CPU resources were 
needed for something of higher quality service. At that time, your background 
calculation would be throttled back until the system goes idle again.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSThread to NSOperation and blockUntil

[Trygve Inda]

I have a thread that is invoked with:

[NSThread detachNewThreadSelector:@selector(threadMethod:) toTarget:self
withObject:self];

It uses NSConditionLock and works well.

This thread performs a complex process but does it slowly so as to not use
much processor time. I specify how long I want it to take (1 to 30 minutes)
and use:

//  block this task until time has elapsed or an exit signal is received.
if ([[self lock] lockWhenCondition:kConditionThreadMustExit beforeDate:[self
blockUntil]])  
 [[self lock] unlock];

blockUntil simply checks to see how much work has been done vs how much time
has passed and if 50% of the work has been done, blocks until 50% of the
time has passed. It works well since the work is very linear.

I would like to move this to NSOperation and NSOperationQueue but I see no
way to replicate this behavior. My current thread is limited to a single
processor core and with NSOperation I could split it to multiple cores, but
in so doing I seem to lose this "delay for a while" bit.

Any ideas?

Thanks.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [NSThread callStackSymbols] weirdness

[Jens Alfke]

> 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 change the final subroutine call plus 
return into a jump. The downside is that the first function will no longer have 
an active stack frame so it won’t show up in backtraces, unless there is a 
symbol file available.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

[NSThread callStackSymbols] weirdness

[Trygve Inda]

I am trying to track down a difficult bug on a customer's machine.

I have inserted [NSThread callStackSymbols] at a critical place in the app
where I want to see how it got there.

When running a debug version, either in the debugger or not, I see:

2/3/16 10:53:51.070 PM MyApp Core[22398]: (
0   MyApp Core -[MyClass dealloc] + 115
1   MyApp Core -[MyClass doSomething:] + 234
2   MyApp Core -[MyClass doStuff:] + 292
3   CoreFoundation __CFNOTIFICATIONCENTER_IS_CALLING_OUT + 12
4   CoreFoundation ___CFXRegistrationPost_block_invoke + 63


When running a release version, even with stripping turned off, I see:

2/3/16 10:57:33.978 PM MyApp Core[23142]: (
0   MyApp CoreMyApp Core + 81817
1   CoreFoundation__CFNOTIFICATIONCENTER_IS_CALLING_OUT + 12
2   CoreFoundation___CFXRegistrationPost_block_invoke + 63


My guess is that it is still being stripped somewhere, but 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?

Thanks,

Trygve



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: -[NSThread start] blocks ?!?

[Jerry Krinock]

> 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.
> 
> After you file the bug report, you might be able to work around it like this:
>defaults write com.apple.dt.Xcode DBGSkipRecordedFrames -bool YES
> then quit and relaunch Xcode.

Just to follow up on this – no bug report because the deadlock has not recurred 
since Sept 26.  So it could indeed be a debugger bugger as you suggest, Greg.  
I had been using Xcode 6 for this project back on Sept. 26, but it is now on 
Xcode 7.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

[Jens Alfke]

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.dylib`syscall_thread_switch + 10
frame #0: 0x000104b4ed92 libsystem_kernel.dylib`syscall_thread_switch + 
10
frame #1: 0x000104b2ddaf libsystem_platform.dylib`_OSSpinLockLockSlow + 
65
frame #2: 0x0001016dba56 Foundation`_NSThreadGet0 + 87
frame #3: 0x0001017d794d Foundation`-[NSThread cancel] + 29
  * frame #4: 0x00010164d83b ThreadFail`-[MyThread 
dealloc](self=0x7fdcb8d328b0, _cmd="dealloc") + 43 at MyThread.m:15
frame #5: 0x000101b62afe 
libobjc.A.dylib`objc_object::sidetable_release(bool) + 232

Calling [self cancel] inside an NSThread’s dealloc method is a bad idea — 
first, it’s not necessary (if the thread’s being dealloced, it can’t be running 
anymore), and second, you’re trying to get the thread to do stuff while it’s in 
the middle of being torn down. That’s probably what’s causing the deadlock.

And since the lock that’s stuck looks like a shared one used by all NSThreads, 
you then get a “tar baby” effect where other NSThread operations also lock up 
as soon as they try to acquire that lock.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: -[NSThread start] blocks ?!?

[Greg Parker]

> 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(beginWithInfo:)
>   object:info] ;
> [worker setName:@“My Worker thread"] ;
> [worker start] ;
> 
> usually this works OK, but sometimes, possibly when the above code executes a 
> second or third time in rapid succession, [worker start] will block forever:
> 
> Thread 1  Queue : com.apple.main-thread (serial)
> #00x7fff93c50cd2 in semaphore_wait_trap ()
> #10x0001007614b4 in _dispatch_semaphore_wait_slow ()
> #20x7fff9134fae2 in -[NSThread start] ()
> 
> Looking at the other threads, I see that “My Worker thread” (see Thread 455, 
> below) has been created, and seems to be stuck while trying to *exit*, which 
> I think is weird because if -[NSThread start] blocked until the new thread 
> exitted, that would defeat the purpose of multithreading.  Same thing if, 
> say, My Worker thread executed some kind of “do this on the main thread” call.
> 
> Should not -[NSThread start] always return before running any of my code in 
> the new thread?  So how could this happen?  I’m running OS X 10.11.

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.

After you file the bug report, you might be able to work around it like this:
defaults write com.apple.dt.Xcode DBGSkipRecordedFrames -bool YES
then quit and relaunch Xcode.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

[Alexey Belkevich]

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 source 
code in there, and apparently the code you’re talking about is buried down 
inside a CocoaPod module. I looked at a couple of source files but didn’t find 
the relevant code.

—Jens

Sure! I've created pretty simple example and posted it to github - 
https://github.com/belkevich/ThreadFail
-- 
Best regards,
Alexey Belkevich


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

[John Daniel]

> 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 
> <http://prod.lists.apple.com/archives/cocoa-dev/2015/Sep/msg00454.html>.
> I have a library, that provide developer-friendly interface to 
> AddressBook.framework. And I unable to use GCD for thread safety, because of 
> `ABAddressBookRegisterExternalChangeCallback` function, that requires a run 
> loop to schedule callback. 
> So I decided to use NSThread subclass. And found that second NSThread 
> instance blocks main thread on `start` method call.
> Here is the source code of Example - 
> https://www.dropbox.com/s/r5k8o28pocu7afk/aptest.zip?dl=0 
> <https://www.dropbox.com/s/r5k8o28pocu7afk/aptest.zip?dl=0>
> When you press 'load contacts' for the second time, it'll block main thread 
> with `semaphore_wait_trap`
> Any ideas?

Why are you using threads at all? If there is a run loop callback, that 
probably means you should schedule it on the run loop. Don’t introduce 
threading unless you are doing something in that callback that blocks the UI. 
Even then, schedule your callback on the UI run loop and have your callback 
spawn the thread or async block.

And that API is deprecated in iOS9 anyway. If you don’t need to support iOS 8 
or earlier, use the new Contacts API.

John Daniel

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

[Jens Alfke]

> 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 source 
code in there, and apparently the code you’re talking about is buried down 
inside a CocoaPod module. I looked at a couple of source files but didn’t find 
the relevant code.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSThread subclass get blocked on 'start' method call

[Alexey Belkevich]

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.
I have a library, that provide developer-friendly interface to 
AddressBook.framework. And I unable to use GCD for thread safety, because of 
`ABAddressBookRegisterExternalChangeCallback` function, that requires a run 
loop to schedule callback. 
So I decided to use NSThread subclass. And found that second NSThread instance 
blocks main thread on `start` method call.
Here is the source code of Example - 
https://www.dropbox.com/s/r5k8o28pocu7afk/aptest.zip?dl=0
When you press 'load contacts' for the second time, it'll block main thread 
with `semaphore_wait_trap`
Any ideas?
-- 
Best regards,
Alexey Belkevich
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: -[NSThread start] blocks ?!?

[John Daniel]

> On Sep 28, 2015, at 12:13 AM, cocoa-dev-requ...@lists.apple.com 
> <mailto: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 starts, there is no way for a seconary thread to call back to 
> the main thread without possibility of deadlock.  It’s a defect in NSThread.
> 
>> Data sharing using serial queues is safer and more robust by design.
> 
> OK, if it is a defect in NSThread, GCD might not have this defect.  I’ll 
> consider that. Thank you.

It is not a defect in NSThread. That is just a subtlety the way it works. In 
this model, there are three potential situations when -[NSThread start] returns:
1) Your thread hasn’t started yet
2) Your thread has started and is running
3) Your thread has completed

Your code must handle all of these possibilities. 

GCD is just a different model and has different subtleties. GCD may not spawn 
any new “threads” at all. You would think in terms of queues and blocks 
instead. 

GCD encourages a more straightforward producer-consumer architecture. You can 
use that architecture for your NSThread code too and get more robust behaviour. 
In general, you really don’t want to think about what your threads might or 
might not be doing or what state they might be in. Use locks around any 
structures that could be shared. Use semaphores to enforce any sequential 
behaviour if you need that.


John Daniel
i...@etresoft.com <mailto:i...@etresoft.com>





John Daniel
i...@etresoft.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: -[NSThread start] blocks ?!?

[Ken Thomases]

> 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 only requirement is that -[NSThread start] is _free_ 
to return _once_ the new thread has started.  That doesn't mean it _will have_ 
returned.  There's no guarantee that -start will return before the new thread 
starts and there never has been.  In fact, it would be very difficult to 
implement such a guarantee.

Now, obviously, you're encountering buggy behavior where -[NSThread start] is 
stuck for some reason.  It's not yet clear whether the bug is in your code or 
in Cocoa.

-Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: -[NSThread start] blocks ?!?

[Charles Srstka]

> On Sep 27, 2015, at 11:18 PM, Jens Alfke  wrote:
> 
>> On Sep 27, 2015, at 8:49 PM, Jerry Krinock > <mailto:je...@ieee.org>> 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 realize that people managed to use NSThread successfully for years 
> before GCD was introduced.
> 
> But if you don't like NSThread's behavior, just use GCD instead.

1. The fact that NSThread is now apparently using dispatch semaphores 
internally suggests that it is no longer implemented the same way that it was 
back when it was the preferred threading mechanism on OS X.

2. The fact that NSThread hasn’t been the preferred threading mechanism for 
quite some years suggests that it may no longer be as thoroughly tested by 
Apple as well as GCD is.

I’d definitely move to GCD, if it were me.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: -[NSThread start] blocks ?!?

[Jens Alfke]

—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 realize that people managed to use NSThread successfully for years 
before GCD was introduced.

But if you don't like NSThread's behavior, just use GCD instead.

--Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: -[NSThread start] blocks ?!?

[Jerry Krinock]

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 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.  It’s a defect in NSThread.

> Data sharing using serial queues is safer and more robust by design.

OK, if it is a defect in NSThread, GCD might not have this defect.  I’ll 
consider that. Thank you.

Jerry


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: -[NSThread start] blocks ?!?

[John Daniel]

> 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:info] ;
> [worker setName:@“My Worker thread"] ;
> [worker start] ;
> 
> usually this works OK, but sometimes, possibly when the above code executes a 
> second or third time in rapid succession, [worker start] will block forever:

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

If this code pre-dates GCD, you could have all kinds of nasty stuff going on. 
All of the items I listed above are shared. They may, or may not, need to be 
protected by locks. There is no way to tell without dumping virtually your 
entire program.

I strongly suggest looking into adopting GCD instead. It dates to 10.5, so you 
aren’t giving up too much backwards compatibility. Data sharing using serial 
queues is safer and more robust by design. You will still need to ensure that 
any shared access uses that serial queue, but I find GCD much more 
straightforward. You may end up blocked in a semaphore again, but it will be 
your own semaphore and you can more easily debug it.

John Daniel


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: -[NSThread start] blocks ?!?

[Jens Alfke]

> 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 microseconds, or at most 
milliseconds. The point is that it’s not guaranteed to happen before the 
calling thread (or any other non-blocked thread in any process) gets to run.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: -[NSThread start] blocks ?!?

[Jerry Krinock]

> 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, the green arrow was stuck at 
-[NSThread start], _dispatch_semaphore_wait_slow() and semaphore_wait_trap().  
It was apparently waiting for a semaphore.

> The scenario I was talking about involved only delays that would eventually 
> be resolved.

OK, I misunderstood.

> All your stack traces have an identical call to _OSSpinLockLockSlow as their 
> second entry. Looks like everything is waiting on a single lock that’s part 
> of the threading machinery.

Interestisng.

> Since you’ve apparently created over 450 threads previously, perhaps you used 
> up kernel resources to the point where whatever took the lock crashed without 
> releasing it?

I should have mentioned that, of those 450 threads, only about 10 were still 
showing in the Debug Navigator, which I presume means that thother 440 have 
finished.

* * *

On 2015 Sep 27, at 03:49, Ken Thomases  wrote:

> It could be a bug in the system libraries, but it could also be any number of 
> other things.  For example, a heap smashing bug could have corrupted a 
> GCD-internal spin lock variable.

Arg.

> You could also try to reproduce the problem with a very much simplified test 
> app.  That would be the first step in filing a bug report, anyway.

Yesterday, this happened once or twice out of 12 trials, while running the last 
10.11 developer preview.  I’ve now updated to the GM candidate and so far good 
after 2 trials.  We’ll see.  I’m not sure I know how to reproduce :(
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: -[NSThread start] blocks ?!?

[Ken Thomases]

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(beginWithInfo:)
>   object:info] ;
> [worker setName:@“My Worker thread"] ;
> [worker start] ;
> 
> usually this works OK, but sometimes, possibly when the above code executes a 
> second or third time in rapid succession, [worker start] will block forever:

> Looking at the other threads, I see that “My Worker thread” (see Thread 455, 
> below) has been created, and seems to be stuck while trying to *exit*, which 
> I think is weird because if -[NSThread start] blocked until the new thread 
> exitted, that would defeat the purpose of multithreading.  Same thing if, 
> say, My Worker thread executed some kind of “do this on the main thread” call.
> 
> Should not -[NSThread start] always return before running any of my code in 
> the new thread?  So how could this happen?  I’m running OS X 10.11.

It could be a bug in the system libraries, but it could also be any number of 
other things.  For example, a heap smashing bug could have corrupted a 
GCD-internal spin lock variable.  Try running with zombies enabled and see if 
you trip one.  Try building and running with Address Sanitizer.  Run the static 
analyzer on your code and make sure to fix any issues it identifies (or examine 
them thoroughly to determine that they're false positives).

You could also try to reproduce the problem with a very much simplified test 
app.  That would be the first step in filing a bug report, anyway.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: -[NSThread start] blocks ?!?

[Quincey Morris]

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 
> deadlock?

I don’t understand what you’re asking. There’s no question of deadlock unless 
the threads wait on each other, directly or indirectly, and you don’t seem to 
have mutual waits in your code. (Of course, it could still happen as an 
unwanted interaction between what your worker thread does and what the system 
does.) The scenario I was talking about involved only delays that would 
eventually be resolved. (I was answering your question, not diagnosing your 
problem.)

All your stack traces have an identical call to _OSSpinLockLockSlow as their 
second entry. Looks like everything is waiting on a single lock that’s part of 
the threading machinery. Since you’ve apparently created over 450 threads 
previously, perhaps you used up kernel resources to the point where whatever 
took the lock crashed without releasing it?

Sorry, I’m not very clever at debugging things like this. :(

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: -[NSThread start] blocks ?!?

[Jerry Krinock]

> 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 
> synchronization mechanisms.
> 
> The *earliest* it can return is before the new thread has had a chance to run 
> initially. But the starter thread is competing for chances to run with every 
> other thread on the system, so it can be delayed by any other thread, 
> including the one it started, up to and beyond the point when the worker 
> thread exits.

Thank you, Quincey.  By “starter thread”, I presume you mean the one which is 
invoking -[NSThread start].  In this case, the “starter thread” is in fact the 
main thread.

This does look like a deadlock between my worker thread and the main thread.  
If what you are saying is true, how could we ever execute 
-performSelectorOnMainThread::: in a secondary thread without possibility of 
deadlock?

This apparent deadlock has been on my MacBook Air, which has only 2 cores, for 
about 3 hours now.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: -[NSThread start] blocks ?!?

[Quincey Morris]

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 thread has had a chance to run 
initially. But the starter thread is competing for chances to run with every 
other thread on the system, so it can be delayed by any other thread, including 
the one it started, up to and beyond the point when the worker thread exits.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

-[NSThread start] blocks ?!?

[Jerry Krinock]

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:info] ;
[worker setName:@“My Worker thread"] ;
[worker start] ;

usually this works OK, but sometimes, possibly when the above code executes a 
second or third time in rapid succession, [worker start] will block forever:

Thread 1  Queue : com.apple.main-thread (serial)
#0  0x7fff93c50cd2 in semaphore_wait_trap ()
#1  0x0001007614b4 in _dispatch_semaphore_wait_slow ()
#2  0x7fff9134fae2 in -[NSThread start] ()

Looking at the other threads, I see that “My Worker thread” (see Thread 455, 
below) has been created, and seems to be stuck while trying to *exit*, which I 
think is weird because if -[NSThread start] blocked until the new thread 
exitted, that would defeat the purpose of multithreading.  Same thing if, say, 
My Worker thread executed some kind of “do this on the main thread” call.

Should not -[NSThread start] always return before running any of my code in the 
new thread?  So how could this happen?  I’m running OS X 10.11.

Jerry

Here is what some of the other threads are doing.  All stacks are completely in 
Apple’s code.

Thread 453  Queue : com.apple.root.default-qos.overcommit (concurrent)
#0  0x7fff93c50d92 in syscall_thread_switch ()
#1  0x7fff9ad85daf in _OSSpinLockLockSlow ()
#2  0x00018135 in gcd_queue_item_enqueue_hook ()
#3  0x00010077e4d9 in _dispatch_introspection_queue_item_enqueue_hook ()
#4  0x00010075ba7c in _dispatch_async_f_slow ()
#5  0x7fff9fe40a1e in 
LSNotificationReceiver::receiveNotificationFromServer(_xpc_connection_s*, 
void*) ()
#6  0x7fff96859986 in _xpc_connection_call_event_handler ()
#7  0x7fff968581ff in _xpc_connection_mach_event ()
#8  0x00010075d5be in _dispatch_client_callout4 ()
#9  0x00010075da65 in _dispatch_mach_msg_invoke ()
#10 0x00010075966e in _dispatch_queue_drain ()
#11 0x00010075c00f in _dispatch_mach_invoke ()
#12 0x000100757df3 in _dispatch_root_queue_drain ()
#13 0x0001007578ed in _dispatch_worker_thread3 ()
#14 0x0001007b6346 in _pthread_wqthread ()
#15 0x0001007b3f9d in start_wqthread ()

Thread 454  Queue : com.apple.root.utility-qos.overcommit (concurrent)
#0  0x7fff93c50d92 in syscall_thread_switch ()
#1  0x7fff9ad85daf in _OSSpinLockLockSlow ()
#2  0x00018d3b in decrement_work_item_refcount ()
#3  0x00018605 in gcd_queue_item_complete_hook ()
#4  0x00010075847c in _dispatch_root_queue_drain ()
#5  0x0001007578ed in _dispatch_worker_thread3 ()
#6  0x0001007b6346 in _pthread_wqthread ()
#7  0x0001007b3f9d in start_wqthread ()

My worker thread (455)
#0  0x7fff93c50d92 in syscall_thread_switch ()
#1  0x7fff9ad85daf in _OSSpinLockLockSlow ()
#2  0x00017af6 in get_entry_from_free_list ()
#3  0x00017a77 in add_thread_info_to_list ()
#4  0x00018143 in gcd_queue_item_enqueue_hook ()
#5  0x00010077e4d9 in _dispatch_introspection_queue_item_enqueue_hook ()
#6  0x000100756cff in _dispatch_barrier_async_f_slow ()
#7  0x7fff9a00be61 in __CFRunLoopSetOptionsReason ()
#8  0x7fff9132f4f0 in -[_NSActivityAssertion _end] ()
#9  0x7fff9132f78c in -[_NSActivityAssertion dealloc] ()
#10 0x7fff92054b18 in objc_object::sidetable_release(bool) ()
#11 0x7fff91389ac4 in __delayedPerformCleanup ()
#12 0x7fff9a033e05 in CFRunLoopTimerInvalidate ()
#13 0x7fff9a0343f2 in __CFRunLoopTimerDeallocate ()
#14 0x7fff99faf383 in CFRelease ()
#15 0x7fff9a0bc983 in CFRunLoopDeallocateTimers_block_invoke ()
#16 0x7fff99ff9bd2 in __CFSetApplyFunction_block_invoke ()
#17 0x7fff99fe4a20 in CFBasicHashApply ()
#18 0x7fff99ff9b6a in CFSetApplyFunction ()
#19 0x7fff9a06eb48 in __CFRunLoopDeallocate ()
#20 0x7fff99faf383 in CFRelease ()
#21 0x7fff9a06e4d4 in __CFTSDFinalize ()
#22 0x0001007b82d9 in _pthread_tsd_cleanup ()
#23 0x0001007b7e60 in _pthread_exit ()
#24 0x0001007b8b2d in pthread_exit ()
#25 0x7fff913befe1 in +[NSThread exit] ()
#26 0x7fff91350098 in __NSThread__start__ ()
#27 0x0001007b6815 in _pthread_body ()
#28 0x0001007b6792 in _pthread_start ()
#29 0x0001007b3fad in thread_start ()

Thread 456
#0  0x7fff93c50d92 in syscall_thread_switch ()
#1  0x7fff9ad85daf in _OSSpinLockLockSlow ()
#2  0x00017af6 in get_entry_from_free_list ()
#3  0x00017a77 in add_thread_info_to_list ()
#4  0x0001007b680e in _pthread_body ()
#5  0x0001007b6792 in _pthread_start 

Re: NSThread

[Raglan T. Tiger]

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 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];
>> 
>> Looking closer, I have to wonder what you think this code will do. You seem 
>> to be trying to create a thread that will message *itself* to do its work.
> 
> Not only that, but I bet it infinite loops restarting itself. 
> 
> 1. Use init, not initWithTarget.
> 2. Override -main to do your threaded work.
> 
> corbin
> 
> 
>> At the time this code is executed, m_mythread will either be nil, or will 
>> point to an older thread instance that you’re about to supersede.
>> 
>> I think you need to take a step back and evaluate your app design. What are 
>> you actually trying to accomplish here? Would using NSOperationQueue or GCD 
>> better suit your needs?
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
>> <mailto:Cocoa-dev@lists.apple.com>)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com 
>> <http://lists.apple.com/>
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/corbind%40apple.com 
>> <https://lists.apple.com/mailman/options/cocoa-dev/corbind%40apple.com>
>> 
>> This email sent to corb...@apple.com <mailto:corb...@apple.com>
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
> <mailto:Cocoa-dev@lists.apple.com>)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com 
> <http://lists.apple.com/>
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/koko%40highrolls.net 
> <https://lists.apple.com/mailman/options/cocoa-dev/koko%40highrolls.net>
> 
> This email sent to k...@highrolls.net <mailto:k...@highrolls.net>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSThread

[Corbin Dunn]

> 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 = [[MYThread alloc] initWithTarget:m_mythread 
>>> selector:@selector(start) object:m_anobject];
>>>  [m_mythread start];
> 
> Looking closer, I have to wonder what you think this code will do. You seem 
> to be trying to create a thread that will message *itself* to do its work.

Not only that, but I bet it infinite loops restarting itself. 

1. Use init, not initWithTarget.
2. Override -main to do your threaded work.

corbin


> At the time this code is executed, m_mythread will either be nil, or will 
> point to an older thread instance that you’re about to supersede.
> 
> I think you need to take a step back and evaluate your app design. What are 
> you actually trying to accomplish here? Would using NSOperationQueue or GCD 
> better suit your needs?
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/corbind%40apple.com
> 
> This email sent to corb...@apple.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSThread

[Mike Abdullah]

> 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:@selector(start) object:m_anobject];
>>   [m_mythread start];

Looking closer, I have to wonder what you think this code will do. You seem to 
be trying to create a thread that will message *itself* to do its work. At the 
time this code is executed, m_mythread will either be nil, or will point to an 
older thread instance that you’re about to supersede.

I think you need to take a step back and evaluate your app design. What are you 
actually trying to accomplish here? Would using NSOperationQueue or GCD better 
suit your needs?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSThread

[Mike Abdullah]

> 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, and 
sample it. More properly, use Instruments. To learn how, try watching some WWDC 
videos on the subject.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSThread

[Raglan T. Tiger]

> 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 the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSThread

[Mike Abdullah]

> 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];
> 
> 
> 
> I set a break in -start and see that this is a separate thread in my process 
> ... so far so good.
> 
> But, my UI becomes unresponsive.
> 
> I understand that the main thread handles the UI so why would it become 
> unresponsive?
> 
> The overall behavior is as if the head code was executing in the main thread.
> 
> Can some light be shed on this?
> 
> I just did 
> 
>[m_bfilenameListFromPath setThreadPriority:0.5];
> 
> before 
> 
>   [m_mythread start];
> 
> with the same result :  unresponsive UI, wait cursor (beach ball) is 
> displayed.

So you have a hang (by the sounds of it on OS X). Step 1 of diagnosis: take a 
sample.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSThread

[Raglan T. Tiger]

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];



I set a break in -start and see that this is a separate thread in my process 
... so far so good.

But, my UI becomes unresponsive.

I understand that the main thread handles the UI so why would it become 
unresponsive?

The overall behavior is as if the head code was executing in the main thread.

Can some light be shed on this?

I just did 

[m_bfilenameListFromPath setThreadPriority:0.5];

before 

[m_mythread start];

with the same result :  unresponsive UI, wait cursor (beach ball) is displayed.


-rags



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [GM-help] [Q] calling OpenMP functions in a thread function for NSThread?

[JongAm Park]

On Jul 29, 2011, at 2:03 PM, Bob Friesenhahn wrote:

> On Fri, 29 Jul 2011, JongAm Park wrote:
>> 
>> is there a problem in calling OpenMP functions in a thread function?
> 
> Possibly there is, however, I recall that your main program uses Objective C. 
>  Perhaps the Objective C runtime does not properly initialize with OpenMP?
> 
> OpenMP does not provide any way to explicitly initialize it.
> 
> Bob


Thanks for your reply.

Right,there is no function like "InitializeOpenMP()", which should be called at 
the beginning.
I set the project to use OpenMP, and if it is just declared statically like :

Magick::Image myImage;

in a normal method, there is no problem.
Only when they are either created or accessed in a thread function, it causes 
the problem.

Apple's GCC has support for OpenMP and it can be turned on/off from a project 
setting, and I turned it on.
The last time I worked with OpenMP was about 3~5 years ago, and at that moment, 
there was no problem.

Let me do some more experiment.
Maybe current version of GCC/LLVM is broken.
( I tested with GCC, LLVM-GCC, LLVM already. )

Thanks again,

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

[Q] calling OpenMP functions in a thread function for NSThread?

[JongAm Park]

Hello,
 
I'm using a GraphicsMagick library in my project.
 
However, there I found a very interesting behavior.
If I create an instance of Magick::Image in a normal method, 
it works OK.
However, if it is implemented in a thread function, it crashes 
when it calls omp_get_max_threads().

I tried these :
 
   1. Declare a pointer to Magick::Image in a class definition 
  and created it dynamically using "new" when I needed it in a thread 
method.
  => When it is being created, it reaches 
 where omp_get_max_threads() is called, 
 and it crashes saying "EXC_BAD_ACCESS".

   2. Declare an instance of Magick::Image in a thread function/method
  => Same crash

   3. Declare the instance of Magick::Image as a global variable 
  and try to use it in a thread function.
  => It crashes when reading a file like image.read( file_name ). 
 Where it crashes is the same to the case 1.
 
So, I thought it could be due to stack size. So, I increased the stack size 
for the thread, but it did'nt solve the problem.
 
is there a problem in calling OpenMP functions in a thread function?
 
Thank you.
JongAm Park___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Question about NSThread

[Ken Thomases]

On Jul 14, 2011, at 9:08 AM, Eric E. Dolecki wrote:

> I haven't done much research, but if I have a method that does a lot of
> looping, can I just safely bust this off (fire and forget)?
> 
> [NSThread detachNewThreadSelector:@selector(generateBigData) toTarget:self
> withObject:nil];

When it comes to threads, you can't ever "just safely" anything.  You have to 
work to make sure your code is thread-safe.  For example, your generateBigData 
method is being invoked on self.  Is it accessing any of self's ivars?  Is it 
accessing _any_ state that will be also be accessed from the main thread or any 
other thread?  If so, you have to ensure that such accesses are safe.

What happens if multiple threads try to set an ivar at the same time?  What 
happens if one is trying to read an ivar while the other is setting it?  Do you 
have ivars that are interrelated such that they have to be changed together to 
be consistent?  If so, then what happens if one thread attempts to read them 
while another has set one but hasn't gotten around to setting the other, yet?  
Etc.

Thread safety doesn't just happen.  You have to design it in and then carefully 
implement it.  There are tons of pitfalls, even for developers who are being 
deliberate and careful.

Good luck,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Question about NSThread

[Eric E. Dolecki]

Thank you for your feedback, I appreciate it.

Eric

On Thu, Jul 14, 2011 at 10:38 AM, Jeff Kelley  wrote:

> You *can*, but there is a limit to the number of threads you can create,
> and
> even if you’re under the limit, you’ll likely be pegging the CPU in an
> inefficient way. You would be better served using GCD and creating a
> dispatch queue, then scheduling the task on that queue (or just using a
> global queue).
>
> Jeff Kelley
>
>
> On Thu, Jul 14, 2011 at 10:08 AM, Eric E. Dolecki  >wrote:
>
> > I haven't done much research, but if I have a method that does a lot of
> > looping, can I just safely bust this off (fire and forget)?
> >
> > [NSThread detachNewThreadSelector:@selector(generateBigData)
> toTarget:self
> > withObject:nil];
> >
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> 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/edolecki%40gmail.com
>
> This email sent to edole...@gmail.com
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Question about NSThread

[Jeff Kelley]

You *can*, but there is a limit to the number of threads you can create, and
even if you’re under the limit, you’ll likely be pegging the CPU in an
inefficient way. You would be better served using GCD and creating a
dispatch queue, then scheduling the task on that queue (or just using a
global queue).

Jeff Kelley


On Thu, Jul 14, 2011 at 10:08 AM, Eric E. Dolecki wrote:

> I haven't done much research, but if I have a method that does a lot of
> looping, can I just safely bust this off (fire and forget)?
>
> [NSThread detachNewThreadSelector:@selector(generateBigData) toTarget:self
> withObject:nil];
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Question about NSThread

[Eric E. Dolecki]

I haven't done much research, but if I have a method that does a lot of
looping, can I just safely bust this off (fire and forget)?

[NSThread detachNewThreadSelector:@selector(generateBigData) toTarget:self
withObject:nil];
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Synthesize getter in a NSThread

[Tony Romano]

Yes, allocating the pool in the loop in conjunction with the drain did the
trick. It wont be too bad in the actual code because my thread is not free
running with a while(1), I use a condition lock.

Thanks for the help guys.

Tony Romano


On 5/21/11 8:31 PM, "Roland King"  wrote:

>both allocate a new pool AND drain it each iteration of the loop
>
>while( 1 )
>{
>pool = [ [ NSAutoReleasePool alloc ] init ];
>
>// do stuff
>
>[ pool drain ];
>}
>
>On 22-May-2011, at 11:28 AM, Tony Romano wrote:
>
>> Unless I misread the documentation on drain, adding a [pool drain]will
>> cause the pool to be deallocated.  I tried it anyways, and I get a
>>couple
>> of emits in the console.
>> 
>> // This message emits when a call to the getter is made
>> 2011-05-21 20:23:39.515 LeakyThread[5947:5707] ***
>> __NSAutoreleaseNoPool(): Object 0x10011d720 of class NSCFString
>> autoreleased with no pool in place - just leaking
>> 
>> // This message emits when a call to pool drain is called.
>> 2011-05-21 20:23:39.515 LeakyThread[5947:5707] *** -[NSAutoreleasePool
>> drain]: This pool has already been drained, do not release it (double
>> release).
>> 
>> 
>> Still not sure what the problem is.
>> Tony Romano
>> 
>> 
>> 
>> On 5/21/11 6:58 PM, "Ken Thomases"  wrote:
>> 
>>> On May 21, 2011, at 3:27 PM, Tony Romano wrote:
>>> 
 I am running into an issue using a synthesized getter in a thread.
 Observing memory consumed by the application in Activity Monitor,
memory
 continues to grow ~200k per sample until the OS gives an Out Of Memory
 warning.  If I code my own getter, the app behaves as expected.  I
have
 striped it down to basically one call as follows:
 
 -(void) process:(LeakyThreadAppDelegate *) myDelegate
 
 {
 
 NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
 
 // Extract the object that contains the thread object
 
 SomeClass *obj = [myDelegate myClass];
 
 NSLog(@"Thread Starting");
 
 // Simplified to illustrate the problem
 
 while (1) {
 
 
 
 if ([[obj thread] isCancelled] == YES) {
 
 break; 
 
 }
 
 }
 
 NSLog(@"Thread Cancelled");
 
 [pool release];
 
 }
 
 
 Any clues as to what is wrong?  Thanks In Advance.
>>> 
>>> A synthesized getter is entitled to put objects into the autorelease
>>> pool.  The above code does not drain the pool until after the thread is
>>> cancelled.  Everything autoreleased before then just accumulates.  Try
>>> draining the pool each iteration of the loop.
>>> 
>>> Regards,
>>> Ken
>>> 
>>> 
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> 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/rols%40rols.org
>> 
>> This email sent to r...@rols.org
>
>


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Synthesize getter in a NSThread

[Roland King]

both allocate a new pool AND drain it each iteration of the loop

while( 1 )
{
pool = [ [ NSAutoReleasePool alloc ] init ];

// do stuff

[ pool drain ];
}

On 22-May-2011, at 11:28 AM, Tony Romano wrote:

> Unless I misread the documentation on drain, adding a [pool drain]will
> cause the pool to be deallocated.  I tried it anyways, and I get a couple
> of emits in the console.
> 
> // This message emits when a call to the getter is made
> 2011-05-21 20:23:39.515 LeakyThread[5947:5707] ***
> __NSAutoreleaseNoPool(): Object 0x10011d720 of class NSCFString
> autoreleased with no pool in place - just leaking
> 
> // This message emits when a call to pool drain is called.
> 2011-05-21 20:23:39.515 LeakyThread[5947:5707] *** -[NSAutoreleasePool
> drain]: This pool has already been drained, do not release it (double
> release).
> 
> 
> Still not sure what the problem is.
> Tony Romano
> 
> 
> 
> On 5/21/11 6:58 PM, "Ken Thomases"  wrote:
> 
>> On May 21, 2011, at 3:27 PM, Tony Romano wrote:
>> 
>>> I am running into an issue using a synthesized getter in a thread.
>>> Observing memory consumed by the application in Activity Monitor, memory
>>> continues to grow ~200k per sample until the OS gives an Out Of Memory
>>> warning.  If I code my own getter, the app behaves as expected.  I have
>>> striped it down to basically one call as follows:
>>> 
>>> -(void) process:(LeakyThreadAppDelegate *) myDelegate
>>> 
>>> {
>>> 
>>> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>>> 
>>> // Extract the object that contains the thread object
>>> 
>>> SomeClass *obj = [myDelegate myClass];
>>> 
>>> NSLog(@"Thread Starting");
>>> 
>>> // Simplified to illustrate the problem
>>> 
>>> while (1) {
>>> 
>>> 
>>> 
>>> if ([[obj thread] isCancelled] == YES) {
>>> 
>>> break; 
>>> 
>>> }
>>> 
>>> }
>>> 
>>> NSLog(@"Thread Cancelled");
>>> 
>>> [pool release];
>>> 
>>> }
>>> 
>>> 
>>> Any clues as to what is wrong?  Thanks In Advance.
>> 
>> A synthesized getter is entitled to put objects into the autorelease
>> pool.  The above code does not drain the pool until after the thread is
>> cancelled.  Everything autoreleased before then just accumulates.  Try
>> draining the pool each iteration of the loop.
>> 
>> Regards,
>> Ken
>> 
>> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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/rols%40rols.org
> 
> This email sent to r...@rols.org

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Synthesize getter in a NSThread

[Tony Romano]

Unless I misread the documentation on drain, adding a [pool drain]will
cause the pool to be deallocated.  I tried it anyways, and I get a couple
of emits in the console.

// This message emits when a call to the getter is made
2011-05-21 20:23:39.515 LeakyThread[5947:5707] ***
__NSAutoreleaseNoPool(): Object 0x10011d720 of class NSCFString
autoreleased with no pool in place - just leaking

// This message emits when a call to pool drain is called.
2011-05-21 20:23:39.515 LeakyThread[5947:5707] *** -[NSAutoreleasePool
drain]: This pool has already been drained, do not release it (double
release).


Still not sure what the problem is.
Tony Romano



On 5/21/11 6:58 PM, "Ken Thomases"  wrote:

>On May 21, 2011, at 3:27 PM, Tony Romano wrote:
>
>> I am running into an issue using a synthesized getter in a thread.
>> Observing memory consumed by the application in Activity Monitor, memory
>> continues to grow ~200k per sample until the OS gives an Out Of Memory
>> warning.  If I code my own getter, the app behaves as expected.  I have
>> striped it down to basically one call as follows:
>> 
>> -(void) process:(LeakyThreadAppDelegate *) myDelegate
>> 
>> {
>> 
>> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>> 
>> // Extract the object that contains the thread object
>> 
>> SomeClass *obj = [myDelegate myClass];
>> 
>> NSLog(@"Thread Starting");
>> 
>> // Simplified to illustrate the problem
>> 
>> while (1) {
>> 
>> 
>> 
>> if ([[obj thread] isCancelled] == YES) {
>> 
>> break; 
>> 
>> }
>> 
>> }
>> 
>> NSLog(@"Thread Cancelled");
>> 
>> [pool release];
>> 
>> }
>> 
>> 
>> Any clues as to what is wrong?  Thanks In Advance.
>
>A synthesized getter is entitled to put objects into the autorelease
>pool.  The above code does not drain the pool until after the thread is
>cancelled.  Everything autoreleased before then just accumulates.  Try
>draining the pool each iteration of the loop.
>
>Regards,
>Ken
>
>


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Synthesize getter in a NSThread

[Ken Thomases]

On May 21, 2011, at 3:27 PM, Tony Romano wrote:

> I am running into an issue using a synthesized getter in a thread.
> Observing memory consumed by the application in Activity Monitor, memory
> continues to grow ~200k per sample until the OS gives an Out Of Memory
> warning.  If I code my own getter, the app behaves as expected.  I have
> striped it down to basically one call as follows:
> 
> -(void) process:(LeakyThreadAppDelegate *) myDelegate
> 
> {
> 
> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> 
> // Extract the object that contains the thread object
> 
> SomeClass *obj = [myDelegate myClass];
> 
> NSLog(@"Thread Starting");
> 
> // Simplified to illustrate the problem
> 
> while (1) {
> 
> 
> 
> if ([[obj thread] isCancelled] == YES) {
> 
> break; 
> 
> }
> 
> }
> 
> NSLog(@"Thread Cancelled");
> 
> [pool release];
> 
> }
> 
> 
> Any clues as to what is wrong?  Thanks In Advance.

A synthesized getter is entitled to put objects into the autorelease pool.  The 
above code does not drain the pool until after the thread is cancelled.  
Everything autoreleased before then just accumulates.  Try draining the pool 
each iteration of the loop.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Synthesize getter in a NSThread

[Tony Romano]

I am running into an issue using a synthesized getter in a thread.
Observing memory consumed by the application in Activity Monitor, memory
continues to grow ~200k per sample until the OS gives an Out Of Memory
warning.  If I code my own getter, the app behaves as expected.  I have
striped it down to basically one call as follows:

-(void) process:(LeakyThreadAppDelegate *) myDelegate

{

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

// Extract the object that contains the thread object

SomeClass *obj = [myDelegate myClass];

NSLog(@"Thread Starting");

// Simplified to illustrate the problem

while (1) {



if ([[obj thread] isCancelled] == YES) {

break; 

}

}

NSLog(@"Thread Cancelled");

[pool release];

}


Any clues as to what is wrong?  Thanks In Advance.

I have created a complete sample and pushed it up to GitHub:
git://github.com/tonyrom/Leaky-Getter-Sample-Code.git

-tony





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSThread

[Bill Bumgarner]

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

A far better approach is to having a single thread that handles all the waiting 
and then spews off the work to be done to a [reasonably sized] pool of threads.

An even better approach than that would be to use GCD.   Do the waiting threads 
wait on something that is covered by dispatch sources?  If so, that solution 
will be significantly cleaner and more efficient than anything you could do 
using the lower level APIs [since GCD can collude with the kernel].   If not, 
dispatching the units of work via the GCD APIs will likely be more efficient 
and generally be simpler than managing a pool of threads.

> 
> my program is a kind of working's Distributor.
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSThread

[Bruno Causse]

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 more than are useful, performant, or optimal...

b.bum

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/bcausse%40lepoint.fr

This email sent to bcau...@lepoint.fr



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSThread

[Bill Bumgarner]

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 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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSThread

[Bruno Causse]

hi all,

how many NSThread i can create?

what happens when the limit is exceeded?

seems [[NSThread alloc] initWithTarget] never returns nil :(

thx a lot
--
Bruno Causse

BEGIN:VCARD
VERSION:3.0
N:Causse;Bruno;;;
FN:Bruno Causse
EMAIL;type=INTERNET;type=HOME;type=pref:bruno.cau...@free.fr
TEL;type=HOME;type=pref:0148997352
item1.ADR;type=HOME;type=pref:;;33\, quai de halage;Créteil;;94000;France
item1.X-ABADR:fr
X-ABUID:B525FD38-719B-4EC3-88E5-B7DEE9A5F246\:ABPerson
END:VCARD


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Issue with NSthread

[Aman (neshu) Agarwal]

Hello,

I am new with COCOA API, I am trying to call function from other class via
object but it's not call it delegate after completion of the procedure while
when I call it on main thread delegate will execute but I am not able to
catch up the data :'(


    [NSThread detachNewThreadSelector:@selector(getserverresponse)
toTarget:self withObject:nil ];  //Object Delegate not working
[self getserverresponse]; //delegate working

getserverresponse call procedure from different class.

-- 
Aman Agarwal
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Difference between NSOperationQueue and NSThread in iOS4?

[David Duncan]

On Aug 25, 2010, at 9:50 AM, Dave Carrigan wrote:

> I would bet that NSOperation on iOS4 is using grand central dispatch, whereas 
> NSOperation on iOS3 probably used NSThreads. In any case, as the other 
> commenter said, doing UI operations on any thread other than the main one is 
> going to cause lots of weirdness.


This is the likely reason. When NSOperation used threads, the threads were 
likely to terminate relatively quickly, taking their runloops with them. When 
the runloop was destroyed, Core Animation would flush its state, allowing the 
changes to your views to occur. Now that NSOperation uses GCD, the threads are 
much longer lived and thus Core Animation's state flush doesn't occur (because 
you aren't running a run loop).
--
David Duncan

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Difference between NSOperationQueue and NSThread in iOS4?

[Dave Carrigan]

On Aug 25, 2010, at 9:41 AM, Scott Andrew wrote:

> I'll need to refigure this out becuase we are trying to load/draw a fairly 
> complex page where the scrollview is transparent and there are several 
> composited buttons on a an almost full screen view.  I am still curious why 
> this would work on OS 3.2 and not on OS 4 and work like butter. I wonder if 
> the threads operations were scheduled differently or started from the main 
> thread originally. The other place i go this idea was from the advanced 
> iphone projects book. 

I would bet that NSOperation on iOS4 is using grand central dispatch, whereas 
NSOperation on iOS3 probably used NSThreads. In any case, as the other 
commenter said, doing UI operations on any thread other than the main one is 
going to cause lots of weirdness.

-- 
Dave Carrigan
d...@rudedog.org
Seattle, WA, USA

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Difference between NSOperationQueue and NSThread in iOS4?

[Scott Andrew]

I'll need to refigure this out becuase we are trying to load/draw a fairly 
complex page where the scrollview is transparent and there are several 
composited buttons on a an almost full screen view.  I am still curious why 
this would work on OS 3.2 and not on OS 4 and work like butter. I wonder if the 
threads operations were scheduled differently or started from the main thread 
originally. The other place i go this idea was from the advanced iphone 
projects book. 

I am not using image views because there was an issue with performance with the 
number of views and scrolling.

Scott

On Aug 25, 2010, at 7:22 AM, Michael Ash wrote:

> On Tue, Aug 24, 2010 at 2:42 PM, Scott Andrew
>  wrote:
>> I have a question that I have been researching but can't find an answer for.
>> 
>> I have some iOS 3.2 code using NSOperation this doesn't work using 
>> NSOperation but works using NSThread withe detatch thread in iOS4 with the 
>> desired effect. My code is basically to create and generate pages for my 
>> paged scrollview in the background. Its basically a play on the WWDC picture 
>> scroller demo. I however have some almost full screen views we prepare in 
>> the background. The code look like:
> [snip]
> 
> UI operations are not generally thread safe. While I couldn't find
> anything specific to UIKit in a quick search on Apple's site (the
> thread safety guide in the iPhone section still talks about NSWindow
> and such, doh!), if it's anything like AppKit, there is very little
> manipulation of views that you can safely do from secondary threads.
> That it's working with NSThread is pure luck. You need to refactor
> your code so that all view manipulation happens on the main thread.
> 
> Mike
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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/scottandrew%40roadrunner.com
> 
> This email sent to scottand...@roadrunner.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Difference between NSOperationQueue and NSThread in iOS4?

[Michael Ash]

On Tue, Aug 24, 2010 at 2:42 PM, Scott Andrew
 wrote:
> I have a question that I have been researching but can't find an answer for.
>
> I have some iOS 3.2 code using NSOperation this doesn't work using 
> NSOperation but works using NSThread withe detatch thread in iOS4 with the 
> desired effect. My code is basically to create and generate pages for my 
> paged scrollview in the background. Its basically a play on the WWDC picture 
> scroller demo. I however have some almost full screen views we prepare in the 
> background. The code look like:
[snip]

UI operations are not generally thread safe. While I couldn't find
anything specific to UIKit in a quick search on Apple's site (the
thread safety guide in the iPhone section still talks about NSWindow
and such, doh!), if it's anything like AppKit, there is very little
manipulation of views that you can safely do from secondary threads.
That it's working with NSThread is pure luck. You need to refactor
your code so that all view manipulation happens on the main thread.

Mike
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Difference between NSOperationQueue and NSThread in iOS4?

[Scott Andrew]

I have a question that I have been researching but can't find an answer for.

I have some iOS 3.2 code using NSOperation this doesn't work using NSOperation 
but works using NSThread withe detatch thread in iOS4 with the desired effect. 
My code is basically to create and generate pages for my paged scrollview in 
the background. Its basically a play on the WWDC picture scroller demo. I 
however have some almost full screen views we prepare in the background. The 
code look like:

-(void) tilePages {

@synchronized(self)
{
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];

CGRect visibleBounds = infoCardScroller.bounds;
NSInteger firstNeededIndex = 
floorf(CGRectGetMinX(visibleBounds)/CGRectGetWidth(visibleBounds));
NSInteger lastNeededIndex = 
floorf((CGRectGetMaxX(visibleBounds)-1)/CGRectGetWidth(visibleBounds));

currentIndex = firstNeededIndex;
firstNeededIndex = MAX(firstNeededIndex-1, 0);
lastNeededIndex = MIN(lastNeededIndex+1, [songs count] - 1);

// recycle no longer visible pages
for (HVInfoCardContainer* infoCard in visibleViews) {
if (infoCard.index < firstNeededIndex || infoCard.index > 
lastNeededIndex) {
[recycledViews addObject:infoCard];
[infoCard removeFromSuperview];
}
}

[visibleViews minusSet:recycledViews];

// add missing pages.
for (int index = firstNeededIndex; index <= lastNeededIndex; index++) {
if (![self isDisplayingContainerForIndex:index]) {
HVInfoCardContainer* container = [self 
dequeueRecycledContainer];

if (container == nil)
container = [[[HVInfoCardContainer alloc] init] 
autorelease];

[self configureContainer:container forIndex:index];
[infoCardScroller addSubview:container];
[visibleViews addObject:container];

}
}

[pool release];
}
;
}



I cached 3 views at most. I basically have the following when the view scrolls:

- (void)scrollViewDidScroll:(UIScrollView *)scrollView; 
{
[[NVGlobalQueue sharedNVGlobalQueue] cancelAllOperations];
[[NVGlobalQueue sharedNVGlobalQueue] 
addOperation:[[[HVInfoCardTileOperation alloc] initWithScroller:self] 
autorelease]];
}

My operations's main is:

-(void) main {
if (!self.isCancelled) {
[self setQueuePriority:NSOperationQueuePriorityVeryHigh];
[scrollerController tilePages];
}
}
}   }
On iOS 3.2 i get what i expect. The third view is created and rendered as we 
scroll to the 2nd one. So i have 3 views in the my scroller full rendered as I 
scroll to the 2nd one. However, on iOS4 this isn't working I don't get my 3rd 
one for a few seconds after its scrolled too. However if i change to:

- (void)scrollViewDidScroll:(UIScrollView *)scrollView {
[NSThread detachNewThreadSelector:@selector(tilePages) toTarget:self 
withObject:nil];
}

This works great and scrolls as smooth as butter. I don't mind doing this since 
there is a check to see if we have to actually create the view (could probably 
make the tileView call even smarter). But why would this not work over 
NSOperation on iOS4 but work in 3.2? Going to the main thread isn't an options 
as it chunks the scroll And no removing the cancelAllOperations doesn't help.

Scott Andrew___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSThread Subclassing problem for Singleton instance

[Kyle Sluder]

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() earlier
> and they worked fine. However this time my thread is not like a simple
> function that will
> quit after it is finished. But my thread needs to be running as teh
> data continuously comes
> from the URL connection.

NSURLConnection already has an asynchronous API. Use that instead of
detaching your own thread.

--Kyle sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSThread Subclassing problem for Singleton instance

[Abhinav Tyagi]

Hi,

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() earlier
and they worked fine. However this time my thread is not like a simple
function that will
quit after it is finished. But my thread needs to be running as teh
data continuously comes
from the URL connection.

My aim was to implement InternetRadio Interface which can
*** connect to an internetradio station specified by stream URL
***  and can transcode the incoming data to WAVE.

As I am working on OSX 10.5 and 10.6, I have derived an interface Internetradio
from NSThread class. To avoid interference with main thread, I have derieved a
class from NSthread so that whole Internetradio functionality work in
separate thread
and doesnt interfere with main thread. As only one radio station is
required to be played
and I should be able to access the radio station details from any
thread for accessing members,
I made the class as singleton.
For Downloading of data from the URL, I am using NSURLConnection which
is a member
of the interface.
Everything works fine but I have noticed a significant problem with my app.
If the main thread calls stopDownload (instance method)
method the internetRadio thread doesnt seems to quit.

The application can be thought of a simple Cocoa App with a single window.
This window have a NATextField and a Button.
We type the URL and click the button.
On clicking the button, the existing station playback or transcoding is stopped
by calling stop download and then it is started again. The starting
and stopping is
done by following mechanism:

Starting the thread:
InternetRadio * pIRadio = [InternetRadio GetInstance];   // Singleton
class method
if( pIRadio == nil)  // this means the thread is either not been
started or was stopped earlier.
pIRadio = [Internetradio pInternetradio]; // calls alloc and init
[pIRadio start];

Stopping the Thread:
Internetradio *pIRadio = [InternetRadio GetInstance];
[pIradio stopDownload];// this method will release all the
memoryallocated and cancels the connection

Every time I click the button to change the radio station, the
Activity Monitor shows thread count which is 1 more than
that was before clicking button.
Although the performance of the app is fine but this behavior is
strange. The documenatation says thread causes
allocation of space due to data structures allocated in kernel as well
as application. Can this be because of similar
reason? And why is the thread count increasing?
Any sample app anybody can suggest please.
Abhi

CODE:


#import "AudioToolbox/AudioToolbox.h"
#import "InternetRadio.h"  // interface definition.
details included in code where member variables are used.
BOOL g_bShouldKeepRunning = FALSE;


@implementation InternetRadio   // class for implementing internet
radio functionality; the interface definition contains some data for
managing the internet radio connection, url etc.

static InternetRadio * pInternetRadio = nil;// singleton instance
-(id) init
{
if( !pInternetRadio){
pInternetRadio =  [super init];
return self;
}
}
//
-(id) pInternetRadio
{
@synchronized(self)
{
if( pInternetRadio == nil)
pInternetRadio = [[self alloc] init];
}
return pInternetRadio;
}
//
+(void) pInternetRadioSetAsNil
{
pInternetRadio = nil;
}
+(id) GetInstance
{
return pInternetRadio;
}
//
-(void) initDownload
{
... some initializations here
[self startDownload];
AudioFileStreamOpen(self, IRPropCallback, IRDataCallback,
kAudioFileAAC_ADTSType, &radioStream);// radiostream is a member
variable of type AudioFileStreamID
}
//
-(void) connection: (NSURLConnection*)connection didreceiveData:(NSData*) data
{
if( AudioFileStreamParseBytes(radioStream, [data length], [data
bytes], 0) != noErr)
NSLog(@"AudioStream  Parser failed!");
[self stopDownload];
}
//
-(void) connection:(NSURLConnection*) connection
didReceiveresponse:(NSURLResponse*) reponse
{
// some metadata etc response code
}
-(void) connection: (NSURLConnection*) connection
didFailWithError:(NSError*) error
{
// some error handling code folowed by [self stopDownload];
}
//
-(void) startDownload:(id)inArgument
{
NSAutoreleasePool *pool = [[NSautoreleasePool alloc] init];
NSURLRequest * theRequest =  [NSURLRequest requestWithURL:radioURL/*
NSURL type member variable*/,

cachePolicy:NSURLRequestUseProtocolcachePolicy timeoutInterval:10];
theConnection/*class member*/ = [[NSURLConnection alloc]
in

Re: Pausing an NSThread

[Jens Alfke]

On Nov 8, 2009, at 2:17 AM, Roland King wrote:

Or look at NSOperation/NSOperationQueue which absolves you of the  
need to care about threads, it's done for you (and I believe makes  
use of Grand Central Dispatch on current versions of OSX). Just  
package up whatever it is you need to do and send it off and some  
thread somewhere will do it for you.


For the record: +1 to this. Let NSOperationQueue manage concurrency  
for you instead of using NSThread, unless you really know what you're  
doing with multithreading. It's much easier and safer.


—Jens___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Pausing an NSThread

[Ron Fleckner]

Many thanks to all who helped with this.  I've had some very useful  
discussion off-list with Roland King and I'm on my way to threading  
nirvana.


Ron
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTextView won't update via NSThread

[Dalton Hamilton]

On Nov 6, 2009, at 5:08 PM, Stephen J. Butler wrote:


On Fri, Nov 6, 2009 at 3:50 PM, Dalton Hamilton  wrote:



Well, from the code you've shown us, you call "[outHandle
readDataToEndOfFile]". Which means it waits for all the data before
updating the view. So yes, the view will be empty until the tool is
complete because that's what you told it to do.



I meant it should update the NSTextView each time a task is called.   
It was waiting until the runCommand was called 30 times and everything  
was done and then suddenly all the text would showup in the  
NSTextView.  It should have blocked until the task was over for each  
log file, then updated the TextView for each entry of runCommand  
method and new task.



If you want to update as the tool outputs stuff, you need to
readInBackgroundAndNotify and run the runloop. You can do all this
without threads...


I like this idea and have been working on this since I received your  
email.

I'm having two problems now:

Two problems.
1.  The first problem is that when I enter runCommand with  
sequentially each time asking it to parse a new log file, the python  
script produces output text but not all the output from the Python  
script makes it to the NSTextView.  The output (or text inside the  
NSTextView) isn't complete for each log file and this seems random.   
This is why, when you look at my code, you'll see a final read after  
the [task waitUntilExit] and that doesn't solve the problem really.
2.  The second problem is the application hangs using this method.  If  
I don't use the readInBackgroundAndNotify and simply use NSThread and  
performSelectorOnMainThread it never hangs and I get full text output.


Here is small piece of my code:
http://web.me.com/dalton/Cocoa_Notes/NSTextView_NSThread.html


Thanks a lot.
Dalton Hamilton

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Pausing an NSThread

[Roland King]

On 08-Nov-2009, at 5:37 PM, Ron Fleckner wrote:





Hi Greg, thanks for the link.

I think I've learned that the effect of pausing a thread can be just  
as easily and more safely achieved by simply stopping it depending  
on a BOOL on the main thread.  Yes?  So, in my situation, I would  
send the new worker thread at creation an ns collection of some  
sort, maybe a dictionary, which contains pointers to my array of  
data and also the index at which to start processing it.


BTW, if you're interested, the work in "// Do some stuff..." is  
creating, via mutable attributed strings, an attributed string for a  
text view on the main window.  At the end of each run through a  
loop, it does [self performSelectorOnMainThread:withObject:wait:]  
which blits the text to the text view.  I _think_ need a new thread  
to do this, which allows the user to see some action from this  
potentially long process (length varies according to the number of  
installed fonts which is in some cases quite high).


Maybe there's a better way?

Anyway, I do appreciate your comments.  Dave DeLong's mini tutorial  
about locks points out that I do need some help and your link helped  
as well.  Now I will do as Kyle suggests and do some more general  
reading (than the docs) about threading before I continue much  
further.  I can still 'experiment' on myself in the meantime.


Ron



Why pause it? Why not just let it finish and next time you have  
something to do, make another thread to do that? Much less work there.


Or look at NSOperation/NSOperationQueue which absolves you of the need  
to care about threads, it's done for you (and I believe makes use of  
Grand Central Dispatch on current versions of OSX). Just package up  
whatever it is you need to do and send it off and some thread  
somewhere will do it for you.


If you have a 'producer-consumer' type problem, where your thread is  
waiting for more data from something else, then go look up producer- 
consumer and see how to implement that with NSCondtion .. or .. use  
NSOperationQueue if each 'operation' is sufficiently standalone (ie  
you're not keeping state in the object you're running on your thread),  
just have the main routine code throw an operation on the queue when  
it wants it.


Or if you just want a thing which happens on a regular (timer) basis,  
but you want that thing to be on a separate thread for some reason,  
run a runloop on the thread, set up an NSTimer to fire and do the  
thing you do when it fires, the runloop will take care of suspending  
the thread until the timer fires.


It is hard to think of any instance in which sleeping a thread for  
1/10th of a second and then polling is the right thing to do. 
___


Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Pausing an NSThread

[Ron Fleckner]

On 08/11/2009, at 4:34 PM, Greg Guerin wrote:


Ron Fleckner wrote:

I've finally worked out a way to pause a thread and would like to  
know if what I'm doing is dangerous or bad or...?


Exactly what problem are you trying to solve?

Pausing a thread is always potentially dangerous.  Any locks or  
@synchronized blocks acquired before reaching the pause-point will  
still be held by the paused thread.  That means any other threads  
waiting for those locks will continue waiting.  And if one of those  
threads happens to be involved with other locks related to whoever  
initiated the pause, then you have deadlock.


It's precisely this potential deadlock that caused Java's suspend()  
method to be deprecated some time ago.


http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

Please read that, then explain what problem you're trying to solve  
by pausing a thread, or using a lock.


I assume it has something to do with your comment "// Do some stuff  
with strings from the array and send the strings to a text view on  
the main window", but without the full explanation, it means  
nothing.  It's about as meaningful as saying "I can call spirits  
from the vasty deep", without giving the incantation, what you will  
bid them do, or whether they will come when you do call for them.


 -- GG


Hi Greg, thanks for the link.

I think I've learned that the effect of pausing a thread can be just  
as easily and more safely achieved by simply stopping it depending on  
a BOOL on the main thread.  Yes?  So, in my situation, I would send  
the new worker thread at creation an ns collection of some sort, maybe  
a dictionary, which contains pointers to my array of data and also the  
index at which to start processing it.


BTW, if you're interested, the work in "// Do some stuff..." is  
creating, via mutable attributed strings, an attributed string for a  
text view on the main window.  At the end of each run through a loop,  
it does [self performSelectorOnMainThread:withObject:wait:] which  
blits the text to the text view.  I _think_ need a new thread to do  
this, which allows the user to see some action from this potentially  
long process (length varies according to the number of installed fonts  
which is in some cases quite high).


Maybe there's a better way?

Anyway, I do appreciate your comments.  Dave DeLong's mini tutorial  
about locks points out that I do need some help and your link helped  
as well.  Now I will do as Kyle suggests and do some more general  
reading (than the docs) about threading before I continue much  
further.  I can still 'experiment' on myself in the meantime.


Ron

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Pausing an NSThread

[Greg Guerin]

Ron Fleckner wrote:

I've finally worked out a way to pause a thread and would like to  
know if what I'm doing is dangerous or bad or...?


Exactly what problem are you trying to solve?

Pausing a thread is always potentially dangerous.  Any locks or  
@synchronized blocks acquired before reaching the pause-point will  
still be held by the paused thread.  That means any other threads  
waiting for those locks will continue waiting.  And if one of those  
threads happens to be involved with other locks related to whoever  
initiated the pause, then you have deadlock.


It's precisely this potential deadlock that caused Java's suspend()  
method to be deprecated some time ago.


http://java.sun.com/j2se/1.4.2/docs/guide/misc/ 
threadPrimitiveDeprecation.html


Please read that, then explain what problem you're trying to solve by  
pausing a thread, or using a lock.


I assume it has something to do with your comment "// Do some stuff  
with strings from the array and send the strings to a text view on  
the main window", but without the full explanation, it means  
nothing.  It's about as meaningful as saying "I can call spirits from  
the vasty deep", without giving the incantation, what you will bid  
them do, or whether they will come when you do call for them.


  -- GG

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Pausing an NSThread

[Ron Fleckner]

On 08/11/2009, at 2:36 PM, Dave DeLong wrote:

Instead of a BOOL on the main thread, what about an NSLock?  Start  
off by locking it on the main thread, and then the secondary thread  
can try to lock it, block (because it can't acquire the lock since  
the main thread has it), and not resume until the main thread  
unlocks it (equivalent to threadPaused = NO).  The only thing is  
that your thread method would need to accept both the arrayOfObjects  
and the lock, unless you were to make the lock somehow globally  
available.


With regards to your code, the myLock variable you have is totally  
worthless.  Locks are used to help coordinate inter-thread  
communication, but in your code, only one thread has myLock.  So it  
locking and unlocking it does nothing except eat cpu cycles.


HTH,

Dave


Aha... now I'm beginning to see the light.  I see also, thanks to  
Kyle, that I need to do some (or a lot of) general background research  
on threading and locks and what it all means.  Thanks very much to  
both of you.



On 08/11/2009, at 2:36 PM, Kyle Sluder wrote:

On Sat, Nov 7, 2009 at 7:28 PM, Ron Fleckner > wrote:

The CPU usage goes down to zero according to Activity Monitor while
the thread is 'paused'.  That's gotta be a good sign.


No, it just means you didn't screw up in an obvious way.  It doesn't
mean you're free of race conditions, corner cases, or other bugs you
haven't tripped on yet.

It would behoove you to read a good introduction to multithreading
that explains condition locks and other threading primitives.  The
Cocoa docs expect you to have this foundation already.  Unfortunately,
I don't have a link handy.  Mind you, even the best tutorial won't
save you from the fact that multithreaded programming is very
difficult, and quite often doesn't get you the results you're looking
for even when done correctly.  This is one reason why the Cocoa APIs
favor runloop-based asynchrony over multithreading.

--Kyle Sluder




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Pausing an NSThread

[Kyle Sluder]

On Sat, Nov 7, 2009 at 7:28 PM, Ron Fleckner  wrote:
> This is a small proof-of-concept/test kind of project. I've had a look at
> NSConditionLock, but I don't get the concepts.  So I've got this naïve
> solution, which is a kind of polling, I know, but it _seems_ to work quite
> well.  The CPU usage goes down to zero according to Activity Monitor while
> the thread is 'paused'.  That's gotta be a good sign.

No, it just means you didn't screw up in an obvious way.  It doesn't
mean you're free of race conditions, corner cases, or other bugs you
haven't tripped on yet.

It would behoove you to read a good introduction to multithreading
that explains condition locks and other threading primitives.  The
Cocoa docs expect you to have this foundation already.  Unfortunately,
I don't have a link handy.  Mind you, even the best tutorial won't
save you from the fact that multithreaded programming is very
difficult, and quite often doesn't get you the results you're looking
for even when done correctly.  This is one reason why the Cocoa APIs
favor runloop-based asynchrony over multithreading.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Pausing an NSThread

[Dave DeLong]

Instead of a BOOL on the main thread, what about an NSLock?  Start off  
by locking it on the main thread, and then the secondary thread can  
try to lock it, block (because it can't acquire the lock since the  
main thread has it), and not resume until the main thread unlocks it  
(equivalent to threadPaused = NO).  The only thing is that your thread  
method would need to accept both the arrayOfObjects and the lock,  
unless you were to make the lock somehow globally available.


With regards to your code, the myLock variable you have is totally  
worthless.  Locks are used to help coordinate inter-thread  
communication, but in your code, only one thread has myLock.  So it  
locking and unlocking it does nothing except eat cpu cycles.


HTH,

Dave

On Nov 7, 2009, at 8:28 PM, Ron Fleckner wrote:


Hi all,

I've finally worked out a way to pause a thread and would like to  
know if what I'm doing is dangerous or bad or...?


This is a small proof-of-concept/test kind of project. I've had a  
look at NSConditionLock, but I don't get the concepts.  So I've got  
this naïve solution, which is a kind of polling, I know, but it  
_seems_ to work quite well.  The CPU usage goes down to zero  
according to Activity Monitor while the thread is 'paused'.  That's  
gotta be a good sign.


After detaching a new thread with [NSThread  
detachNewThreadSelector:@selector(mySelector:) toTarget:self  
withObject:[self arrayOfObjects]];


// New thread starts here
- (void)mySelector:(id)anObject
{
   NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
   NSLock *myLock = [[NSLock alloc] init];
   int loopCounter = 0;
   int num = [anObject count]; // it's an NSArray
   BOOL isPaused;

   while (loopCounter < num)
   {
   [myLock lock];
   isPaused = [self threadPaused];// -threadPaused is a BOOL on  
main thread

   [myLock unlock];
   if (isPaused)
   {
   while (isPaused)
   {
   usleep(1000 * 100); // one tenth of a second
   [myLock lock];
   isPaused = [self threadPaused];
   [myLock unlock];
}
}
// Do some stuff with strings from the array and send the  
strings to a text view on the main window

loopCounter++;
   }


   [self performSelectorOnMainThread:@selector 
(stopProgAnimation) withObject:nil waitUntilDone:NO];

   [myLock release];
   [pool release];
}


Thanks in advance for any insight.  My skin is fairly thick, so if  
you see something truly awful, please tell me.


Ron

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/davedelong%40me.com

This email sent to davedel...@me.com




smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Pausing an NSThread

[Ron Fleckner]

Hi all,

I've finally worked out a way to pause a thread and would like to know  
if what I'm doing is dangerous or bad or...?


This is a small proof-of-concept/test kind of project. I've had a look  
at NSConditionLock, but I don't get the concepts.  So I've got this  
naïve solution, which is a kind of polling, I know, but it _seems_ to  
work quite well.  The CPU usage goes down to zero according to  
Activity Monitor while the thread is 'paused'.  That's gotta be a good  
sign.


After detaching a new thread with [NSThread  
detachNewThreadSelector:@selector(mySelector:) toTarget:self  
withObject:[self arrayOfObjects]];


// New thread starts here
- (void)mySelector:(id)anObject
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSLock *myLock = [[NSLock alloc] init];
int loopCounter = 0;
int num = [anObject count]; // it's an NSArray
BOOL isPaused;

while (loopCounter < num)
{
[myLock lock];
isPaused = [self threadPaused];// -threadPaused is a BOOL on  
main thread

[myLock unlock];
if (isPaused)
{
while (isPaused)
{
usleep(1000 * 100); // one tenth of a second
[myLock lock];
isPaused = [self threadPaused];
[myLock unlock];
 }
 }
 // Do some stuff with strings from the array and send the  
strings to a text view on the main window

 loopCounter++;
}


[self  
performSelectorOnMainThread:@selector(stopProgAnimation)  
withObject:nil waitUntilDone:NO];

[myLock release];
[pool release];
}


Thanks in advance for any insight.  My skin is fairly thick, so if you  
see something truly awful, please tell me.


Ron

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTextView won't update via NSThread

[Stephen J. Butler]

On Thu, Nov 5, 2009 at 6:20 AM, Dalton Hamilton  wrote:
> Does anyone have any idea why NSTextView won't update when the code is a
> thread?

Because everything in AppKit is thread-unsafe, unless specifically marked safe.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTextView won't update via NSThread

[Ken Thomases]

On Nov 5, 2009, at 6:20 AM, Dalton Hamilton wrote:

Does anyone have any idea why NSTextView won't update when the code  
is a thread?


Yes, because Cocoa generally doesn't support manipulating the GUI from  
any thread other than the main thread.


Read through this:
http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/Multithreading/Introduction/Introduction.html

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSTextView won't update via NSThread

[Dalton Hamilton]

Hello, I'm doing the below and when I call the  -runTask: method is  
called from the main run loop (no threading) with


[self runTask:self];

 the NSTextView updates great; however, when I call -runTask via

		[NSThread detachNewThreadSelector:@selector(runTask:) toTarget:self  
withObject:nil];


my app hangs on the attempt to update the myTextView NSTextView

[[[myTextView textStorage] mutableString] appendString:outString];  

Does anyone have any idea why NSTextView won't update when the code is  
a thread?

Thanks a lot for any advice.

Dalton Hamilton
Chapel Hill, NC
=
- (void)runTask:(id)sender
{
NSTask *task = [[NSTask alloc] init];
NSPipe *inPipe = [NSPipe pipe], *outPipe = [NSPipe pipe];
NSFileHandle *outHandle = [outPipe fileHandleForReading];
NSData *outData;
NSString *outString;


	NSMutableArray 		*arguments = [NSMutableArray arrayWithObjects: @"- 
l", nil];

[arguments addObject:@"/Applications"];


[task setLaunchPath:@"/bin/ls"];


//-
[task setArguments: arguments];
[task setStandardOutput:outPipe];
[task setStandardError:outPipe];
[task setStandardInput:inPipe];
[task launch];


outData = [outHandle readDataToEndOfFile];
[task waitUntilExit];
[task release];

outString = [[NSString alloc] initWithData:outData
  
encoding:NSUTF8StringEncoding];
NSLog(@"%...@\n\n",outString);
[[[myTextView textStorage] mutableString] appendString:outString];  

// I've also just tried to do
// [myTextView setString:outString];
// and it also hangs when NSThread is used


}
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: about NSThread crash

[Ken Thomases]

On Jun 24, 2009, at 1:49 AM, Chris（吴潮江） wrote:


On Jun 24, 2009, at 2:28 AM, Ken Thomases wrote:


You probably don't need to use a background thread to do FTP.  You  
can  do it using asynchronous methods on the main thread.  Since  
you can,  you probably should.  It's almost always less error prone  
and even  more efficient.


Considering the GUI operations, I use the background thread to do FTP.


But using _asynchronous_ methods for the FTP won't interfere with GUI  
operations.


There are several asynchronous APIs you could use.  You could use  
NSURLConnection and the related classes (see the URL Loading System  
documentation).  You can use NSStream, possibly in combination with  
CFStream and, in particular, CFFTPStream.


Each of these is based on run loops, so you don't block the main  
thread waiting for something to happen, you just respond when it does.




How are you pausing and resuming the download?
As you said, through controlling this from the GUI, when user click  
the pause
button, I will stop receiving the data in the background and exit  
the thread.


No offense, but if that's your answer, then I think you don't  
appreciate the nuances in the question.  And if you don't appreciate  
the nuances, then you're probably getting them wrong.


Since the GUI operations occur on the main thread, and since you're  
using a background thread for the FTP operations, it's not easy to  
_correctly_ pause, resume, or cancel the FTP download in response to a  
GUI operation.  If you think it is easy or direct, then it's probably  
not correct.


So, I ask again: what _specific_ techniques are you using to respond  
to a GUI action and then pause, resume, or cancel the FTP operation?   
You probably need to show code, or at least describe the design in  
technical detail, if we're going to try to help you figure out what's  
going wrong.


Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: about NSThread crash

[Chris（吴潮江）]

On Jun 24, 2009, at 2:28 AM, Ken Thomases wrote:


You probably don't need to use a background thread to do FTP.  You can  do 
it using asynchronous methods on the main thread.  Since you can,  you 
probably should.  It's almost always less error prone and even  more 
efficient.



Considering the GUI operations, I use the background thread to do FTP.



How are you pausing and resuming the download?

As you said, through controlling this from the GUI, when user click the
pause button, I will stop receiving the data in the background and exit the
thread.


Doing it the "naive" way will get you in trouble.
 In fact, In Windows platform, I control it successful with the same 
methods.

 Maybe it is really "naive" way in the Mac platform.


You should launch the program in the debugger, instead -- use Debug 
instead of  Run.  That way, it will reliably show you the proper thread in 
the  event of a crash.

According to your suggestion, I will try to do it.

Thanks.

Regards,
Chris


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: about NSThread crash

[Ken Thomases]

On Jun 24, 2009, at 1:12 AM, Chris（吴潮江） wrote:

I have some problems when to using thread. As we all know, there is  
a method to create a thread,
+ (void)detachNewThreadSelector:(SEL)aSelector toTarget:(id)aTarget  
withObject:(id)anArgument.

- (void)aSelector:(id)anArgument
{
   NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
   //  Here I implement FTP functions. e.g. download/ pause  
download/ resume download file.

   [pool release];
   [NSThread exit];
}


You probably don't need to use a background thread to do FTP.  You can  
do it using asynchronous methods on the main thread.  Since you can,  
you probably should.  It's almost always less error prone and even  
more efficient.



To my surprise, when downloading a file, I pause download and no  
error display. Then I resume to download file,

it's ok.


How are you pausing and resuming the download?  I assume the user is  
controlling this from the GUI.  If so, how are you communicating this  
request to the background thread?  How is the background thread  
receiving and acting on the request?  When you use multiple threads,  
you have to be very careful and deliberate about how you do things  
like this.  Doing it the "naive" way will get you in trouble.


However, at this time I pause download file, there will be a error  
showing EXC_BAD_ACCESS and the stack

information is:
mach_msg_trap
mach_msg
CFRunLoopRunSpecific
CFRunLoopRunInMode
RunCurrentEventLoopInMode
ReceiveNextEventCommon
BlockUnitlNextEventMatchingListInMode
_DPSNextEvent
_[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
_[NSApplication run]
NSApplicationMain


This is the stack for the main thread.  Judging from its normality,  
it's probably not the thread on which the exception occurred.  The  
debugger is showing you an arbitrary thread.  This can happen if you  
rely on Xcode's "auto-attach debugger on crash" feature.  You should  
launch the program in the debugger, instead -- use Debug instead of  
Run.  That way, it will reliably show you the proper thread in the  
event of a crash.


Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

about NSThread crash

[Chris（吴潮江）]

Hi,
I have some problems when to using thread. As we all know, there is a method to 
create a thread,  
+ (void)detachNewThreadSelector:(SEL)aSelector toTarget:(id)aTarget 
withObject:(id)anArgument.
- (void)aSelector:(id)anArgument
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
//  Here I implement FTP functions. e.g. download/ pause download/ resume 
download file.
[pool release];
[NSThread exit];
}
To my surprise, when downloading a file, I pause download and no error display. 
Then I resume to download file,
it's ok. However, at this time I pause download file, there will be a error 
showing EXC_BAD_ACCESS and the stack
information is:
mach_msg_trap
mach_msg
CFRunLoopRunSpecific
CFRunLoopRunInMode
RunCurrentEventLoopInMode
ReceiveNextEventCommon
BlockUnitlNextEventMatchingListInMode
_DPSNextEvent
_[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
_[NSApplication run]
NSApplicationMain

I don't know why? 
Please tell me the reason if anyone knows.
Thanks.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSURLConnection vs. NSThread

[Michael Ash]

On Fri, May 15, 2009 at 12:56 PM, Luke the Hiesterman
 wrote:
>
> On May 14, 2009, at 5:35 PM, Michael Ash wrote:
>
>> I agree completely that the simplest code should win, but I also think
>> that the thread adds complexity, not just overhead.
>
> My point is that some programmers might find using NSThread fits their way
> of thinking best. Others might find NSURLConnection fits best. I encourage
> the individual programmer here to go with his or her gut.

Going with your gut is usually a bad idea in any case, but it's
especially bad when you have zero experience with either approach.
Asking others for their opinions in that case is often a good idea.

Mike
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSURLConnection vs. NSThread

[Luke the Hiesterman]

On May 14, 2009, at 5:35 PM, Michael Ash wrote:


I agree completely that the simplest code should win, but I also think
that the thread adds complexity, not just overhead.


My point is that some programmers might find using NSThread fits their  
way of thinking best. Others might find NSURLConnection fits best. I  
encourage the individual programmer here to go with his or her gut.


Luke
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSURLConnection vs. NSThread

[Eric E. Dolecki]

I'm going to try NSURLConnection first I guess and see how it goes. I'm
loading larger images that get resized down in the table so I'll have the
larger images cached for display in a details view.
Thanks for all of this valuable feedback!
Eric

On Thu, May 14, 2009 at 11:21 PM, George Warner  wrote:

> On Thu, 14 May 2009 16:52:48 -0400, Eric E. Dolecki" 
>  wrote:
>
> Just curious, but if I am loading images into a UIImageView in table cells
> from online URLs, is it better to use NSThread or use async NSURLConnection
> to ensure that the scrolling is smooth while images are loaded in?
>
>
> This probably depends on how long the async callback takes; more than about
> 1/10th of a second and it will start impacting the smoothness of the
> scrolling.
> I'd write it async first and if the scrolling isn't smooth I'd move it to
> its own thread.
>  --
> Enjoy,
> George Warner,
> Schizophrenic Optimization Scientist
> Apple Developer Technical Support (DTS)
>
>


-- 
http://ericd.net
Interactive design and development
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSURLConnection vs. NSThread

[George Warner]

On Thu, 14 May 2009 16:52:48 -0400, Eric E. Dolecki"  
 wrote:
Just curious, but if I am loading images into a UIImageView in table  
cells
from online URLs, is it better to use NSThread or use async  
NSURLConnection

to ensure that the scrolling is smooth while images are loaded in?



This probably depends on how long the async callback takes; more than  
about 1/10th of a second and it will start impacting the smoothness of  
the scrolling.


I'd write it async first and if the scrolling isn't smooth I'd move it  
to its own thread.

--
Enjoy,
George Warner,
Schizophrenic Optimization Scientist
Apple Developer Technical Support (DTS)

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSURLConnection vs. NSThread

[Michael Ash]

On Thu, May 14, 2009 at 6:42 PM, Luke the Hiesterman  wrote:
> To add to that thought, I should add that even if there is a performance
> difference, I'd be surprised if it's anything that anyone would notice. It's
> generally a mistake to assume there's a performance problem with a certain
> approach until you've actually seen the performance problem. In cases like
> this, I would say that what makes sense to the programmer, and what makes
> the most simple code should trump what's fastest unless someone can show a
> tangible gain in one way over the other.

Certainly the overhead is highly unlikely to matter for this
situation. It could become significant if you're loading many hundreds
of images simultaneously, and the problem will transition from
"overhead" to "bug" as you pass about 2600 simultaneous loads due to
the inherent per-process thread limit in OS X.

(If you wanted to avoid the problem for such an unreasonable number of
simultaneous loads, NSOperationQueue is probably the way to go.)

I agree completely that the simplest code should win, but I also think
that the thread adds complexity, not just overhead.

Mike
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSURLConnection vs. NSThread

[Mike Abdullah]

I am not saying that the threads created by NSURLConnection are in any  
way faster than those created manually. I am saying that  
NSURLConnection is going to use its own thread internally whatever you  
do, so throwing another thread into the mix is only adding additional  
overhead.


As it happens, NSURLConnection's thread implementation is also likely  
to be more efficient that anyone's custom one because it uses a single  
thread for all connections. After starting your first URL load, the  
overhead of creating a fresh thread never happens again.


Mike.

On 14 May 2009, at 23:42, Luke the Hiesterman wrote:

To add to that thought, I should add that even if there is a  
performance difference, I'd be surprised if it's anything that  
anyone would notice. It's generally a mistake to assume there's a  
performance problem with a certain approach until you've actually  
seen the performance problem. In cases like this, I would say that  
what makes sense to the programmer, and what makes the most simple  
code should trump what's fastest unless someone can show a tangible  
gain in one way over the other.


Luke

On May 14, 2009, at 3:39 PM, Luke the Hiesterman wrote:

Why is it assumed that threads created by NSURLConnection are  
faster than threads created manually with NSThread?


Luke

On May 14, 2009, at 3:36 PM, Mike Abdullah wrote:


Threads would be unnecessary hassle and probably slower performing.

NSURLConnection maintains its own private thread for performing  
the work of all open URL connections, even if you are using the  
synchronous API. By using NSThread, you are just bringing an extra  
unnecessary thread into the mix (possibly more if you're planning  
1 thread per-image) and then have to co-ordinate between it and  
the main thread. The async NSURLConnection API takes care of that  
for you already.


The only possible performance bottleneck that a thread might  
benefit you is turning the downloaded image data into a UIImage.  
If you find that is being slow, then maybe consider a thread-based  
solution for that portion of the work.


Mike.

On 14 May 2009, at 21:52, Eric E. Dolecki wrote:

Just curious, but if I am loading images into a UIImageView in  
table cells
from online URLs, is it better to use NSThread or use async  
NSURLConnection

to ensure that the scrolling is smooth while images are loaded in?

Eric
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/cocoadev%40mikeabdullah.net

This email sent to cocoa...@mikeabdullah.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/luketheh 
%40apple.com


This email sent to luket...@apple.com




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/cocoadev%40mikeabdullah.net

This email sent to cocoa...@mikeabdullah.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSURLConnection vs. NSThread

[Alastair Houghton]

On 14 May 2009, at 23:39, Luke the Hiesterman wrote:

Why is it assumed that threads created by NSURLConnection are faster  
than threads created manually with NSThread?


It isn't.

Mike's point is that the chances of someone who is asking whether or  
not to use NSThread on a developer mailing list doing a better job of  
using NSThread than whoever at Apple (or NeXT) wrote NSURLConnection  
are slim.


Moreover, NSURLConnection's implementation (threading model, for  
instance) may change over time to better fit with developments to the  
operating system.  I can imagine some changes that might be coming in  
a future release of OS X, for instance, as I am sure can many others.


Your own NSThread won't benefit from those changes unless you rewrite  
it.


In any event, I would always prefer a pre-existing asynchronous API to  
effectively rolling my own (which is what you'd have to do anyway if  
you were using your own thread).  Even if it isn't going to run any  
faster, it's going to be a damn sight faster to implement than rolling  
your own, and it's likely to have fewer bugs to boot.


Kind regards,

Alastair.

--
http://alastairs-place.net



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSURLConnection vs. NSThread

[Luke the Hiesterman]

To add to that thought, I should add that even if there is a  
performance difference, I'd be surprised if it's anything that anyone  
would notice. It's generally a mistake to assume there's a performance  
problem with a certain approach until you've actually seen the  
performance problem. In cases like this, I would say that what makes  
sense to the programmer, and what makes the most simple code should  
trump what's fastest unless someone can show a tangible gain in one  
way over the other.


Luke

On May 14, 2009, at 3:39 PM, Luke the Hiesterman wrote:

Why is it assumed that threads created by NSURLConnection are faster  
than threads created manually with NSThread?


Luke

On May 14, 2009, at 3:36 PM, Mike Abdullah wrote:


Threads would be unnecessary hassle and probably slower performing.

NSURLConnection maintains its own private thread for performing the  
work of all open URL connections, even if you are using the  
synchronous API. By using NSThread, you are just bringing an extra  
unnecessary thread into the mix (possibly more if you're planning 1  
thread per-image) and then have to co-ordinate between it and the  
main thread. The async NSURLConnection API takes care of that for  
you already.


The only possible performance bottleneck that a thread might  
benefit you is turning the downloaded image data into a UIImage. If  
you find that is being slow, then maybe consider a thread-based  
solution for that portion of the work.


Mike.

On 14 May 2009, at 21:52, Eric E. Dolecki wrote:

Just curious, but if I am loading images into a UIImageView in  
table cells
from online URLs, is it better to use NSThread or use async  
NSURLConnection

to ensure that the scrolling is smooth while images are loaded in?

Eric
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/cocoadev%40mikeabdullah.net

This email sent to cocoa...@mikeabdullah.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/luketheh%40apple.com

This email sent to luket...@apple.com




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSURLConnection vs. NSThread

[Luke the Hiesterman]

Why is it assumed that threads created by NSURLConnection are faster  
than threads created manually with NSThread?


Luke

On May 14, 2009, at 3:36 PM, Mike Abdullah wrote:


Threads would be unnecessary hassle and probably slower performing.

NSURLConnection maintains its own private thread for performing the  
work of all open URL connections, even if you are using the  
synchronous API. By using NSThread, you are just bringing an extra  
unnecessary thread into the mix (possibly more if you're planning 1  
thread per-image) and then have to co-ordinate between it and the  
main thread. The async NSURLConnection API takes care of that for  
you already.


The only possible performance bottleneck that a thread might benefit  
you is turning the downloaded image data into a UIImage. If you find  
that is being slow, then maybe consider a thread-based solution for  
that portion of the work.


Mike.

On 14 May 2009, at 21:52, Eric E. Dolecki wrote:

Just curious, but if I am loading images into a UIImageView in  
table cells
from online URLs, is it better to use NSThread or use async  
NSURLConnection

to ensure that the scrolling is smooth while images are loaded in?

Eric
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/cocoadev%40mikeabdullah.net

This email sent to cocoa...@mikeabdullah.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/luketheh%40apple.com

This email sent to luket...@apple.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSURLConnection vs. NSThread

[Mike Abdullah]

Threads would be unnecessary hassle and probably slower performing.

NSURLConnection maintains its own private thread for performing the  
work of all open URL connections, even if you are using the  
synchronous API. By using NSThread, you are just bringing an extra  
unnecessary thread into the mix (possibly more if you're planning 1  
thread per-image) and then have to co-ordinate between it and the main  
thread. The async NSURLConnection API takes care of that for you  
already.


The only possible performance bottleneck that a thread might benefit  
you is turning the downloaded image data into a UIImage. If you find  
that is being slow, then maybe consider a thread-based solution for  
that portion of the work.


Mike.

On 14 May 2009, at 21:52, Eric E. Dolecki wrote:

Just curious, but if I am loading images into a UIImageView in table  
cells
from online URLs, is it better to use NSThread or use async  
NSURLConnection

to ensure that the scrolling is smooth while images are loaded in?

Eric
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/cocoadev%40mikeabdullah.net

This email sent to cocoa...@mikeabdullah.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSURLConnection vs. NSThread

[Luke the Hiesterman]

I actually think for a simple case like this one, the NSThread  
approach will have simpler, more straightforward code. I say go with  
whichever way makes more sense for your style of coding.


Luke

On May 14, 2009, at 2:56 PM, Michael Ash wrote:

On Thu, May 14, 2009 at 4:52 PM, Eric E. Dolecki  
 wrote:
Just curious, but if I am loading images into a UIImageView in  
table cells
from online URLs, is it better to use NSThread or use async  
NSURLConnection

to ensure that the scrolling is smooth while images are loaded in?


I'd recommend the async method if it's at all reasonable. Threads are
difficult to write, dangerous to use, and difficult to debug. If you
can avoid them without blocking your app or causing major coding
headaches, then it's generally best to avoid them.

Mike
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/luketheh%40apple.com

This email sent to luket...@apple.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSURLConnection vs. NSThread

[Michael Ash]

On Thu, May 14, 2009 at 4:52 PM, Eric E. Dolecki  wrote:
> Just curious, but if I am loading images into a UIImageView in table cells
> from online URLs, is it better to use NSThread or use async NSURLConnection
> to ensure that the scrolling is smooth while images are loaded in?

I'd recommend the async method if it's at all reasonable. Threads are
difficult to write, dangerous to use, and difficult to debug. If you
can avoid them without blocking your app or causing major coding
headaches, then it's generally best to avoid them.

Mike
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSURLConnection vs. NSThread

[Eric E. Dolecki]

Just curious, but if I am loading images into a UIImageView in table cells
from online URLs, is it better to use NSThread or use async NSURLConnection
to ensure that the scrolling is smooth while images are loaded in?

Eric
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Cancel NSThread - cocoa/mysql database search...

[Andrew Farmer]

On 08 May 09, at 07:08, spartan g wrote:
But the problem I am facing now is, once i sent the query to MySQL  
through
SMySQL framework, I am unable to cancel it. This query takes so much  
time to

return the results and cannot be canceled as far as I understand.
Is there any way to cancel this query??? any command or API!!!


No. The MySQL C API [1] is synchronous, and provides no method to  
cancel a query that's in progress. Indeed, the network protocol  
doesn't either - the only way to stop a query that's running is by  
using the MySQL KILL command to terminate the connection.


If you are ending up with queries that run for 15 to 20 minutes, you  
probably need to do one or more of the following:


 1. Adjust your database schema to make these queries run faster
 2. Fetch smaller chunks of data at a time using the LIMIT modifier  
on queries

 3. Change your application so that it performs more efficient queries

All of these are really outside the scope of Cocoa development,  
though. You may have better results asking on a MySQL-specific mailing  
list or forum.


[1]: http://dev.mysql.com/doc/refman/5.1/en/c.html
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Cancel NSThread - cocoa/mysql database search...

[spartan g]

Thanks...

I tried both the ways as Bill and Mike suggested.
I could manage to cancel the thread by checking the bool flag for
cancellation.
It works fine.

But the problem I am facing now is, once i sent the query to MySQL through
SMySQL framework, I am unable to cancel it. This query takes so much time to
return the results and cannot be canceled as far as I understand.
Is there any way to cancel this query??? any command or API!!!

Once again Thanks guys...

--
Best Regards,
Sparta...


On Wed, May 6, 2009 at 9:34 PM, Bill Bumgarner  wrote:

> On May 6, 2009, at 8:22 AM, Sparta wrote:
>
>> I am working on cocoa – MySQL application that connects to the MySQL
>> database and retrieves the records.
>> I run the search in a NSThread. I wish to cancel the search if needed, as
>> the searching of the desired data takes 15-20 minutes due to the bigger
>> size
>> of database.
>>
>> Please suggest some method which can cancel / exit the NSThread from the
>> parent thread.
>>
>
> Something like this:
>
> 
>BOOL stopItMan;
> 
>
> - (void) doSomePotentiallyLongWindedStuffOnASecondThread
> {
>while (!stopItMan) {
> do some more stuff 
>};
> }
>
> - (void) userIsImpatientStopItNow
> {
>stopItMan = YES;
> }
>
> Don't do something like this (which is possible and would require calling
> through to some bits of lower level mach or pthread API):
>
> - (void) userIsImpatientStopItNow
> {
>nukeBackgroundThreadFromSpace();
> }
>
> You can't kill a thread arbitrarily as there is no way to know what state
> the thread might be in when you kill it unless you do the work necessary to
> cause the targeted thread to be blocked at a known safe point in its
> execution.   However, if the thread is blocked at a known safe point, that
> known safe point can just as easily be a test to see if should continue,
> exiting safely if not.
> b.bum
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Cancel NSThread - cocoa/mysql database search...

[Bill Bumgarner]

On May 6, 2009, at 8:22 AM, Sparta wrote:

I am working on cocoa – MySQL application that connects to the MySQL
database and retrieves the records.
I run the search in a NSThread. I wish to cancel the search if  
needed, as
the searching of the desired data takes 15-20 minutes due to the  
bigger size

of database.

Please suggest some method which can cancel / exit the NSThread from  
the

parent thread.


Something like this:


BOOL stopItMan;


- (void) doSomePotentiallyLongWindedStuffOnASecondThread
{
while (!stopItMan) {
 do some more stuff 
};
}

- (void) userIsImpatientStopItNow
{
stopItMan = YES;
}

Don't do something like this (which is possible and would require  
calling through to some bits of lower level mach or pthread API):


- (void) userIsImpatientStopItNow
{
nukeBackgroundThreadFromSpace();
}

You can't kill a thread arbitrarily as there is no way to know what  
state the thread might be in when you kill it unless you do the work  
necessary to cause the targeted thread to be blocked at a known safe  
point in its execution.   However, if the thread is blocked at a known  
safe point, that known safe point can just as easily be a test to see  
if should continue, exiting safely if not.

b.bum___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Cancel NSThread - cocoa/mysql database search...

[Michael Ash]

On Wed, May 6, 2009 at 11:22 AM, Sparta  wrote:
> Hi Friends,
>
> I am working on cocoa ­ MySQL application that connects to the MySQL
> database and retrieves the records.
> I run the search in a NSThread. I wish to cancel the search if needed, as
> the searching of the desired data takes 15-20 minutes due to the bigger size
> of database.
>
> Please suggest some method which can cancel / exit the NSThread from the
> parent thread.

You can't. Thread cancellation is extremely dangerous. You might kill
the thread while it's in the middle of holding an exclusive resource.
That resource would then never be released, which could freeze up your
entire application. As such, NSThread has no way to kill a thread.

The best way to do this is to ask the thread to quit, and have the
thread check periodically. NSThread on 10.5 has a built-in way to do
this, the misleadingly-named -cancel and -isCancelled methods. Check
-isCancelled every so often, and send -cancel when you want the thread
to quit. You may have to redesign your code so that it can check
-isCancelled frequently, though.

Mike
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Cancel NSThread - cocoa/mysql database search...

[Sparta]

Hi Friends,

I am working on cocoa ­ MySQL application that connects to the MySQL
database and retrieves the records.
I run the search in a NSThread. I wish to cancel the search if needed, as
the searching of the desired data takes 15-20 minutes due to the bigger size
of database.

Please suggest some method which can cancel / exit the NSThread from the
parent thread.
   
-- 
Thanks and Regards,
Sparta...

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSRunLoop vs. NSThread sleep

[Michael Ash]

On Wed, Apr 29, 2009 at 6:53 AM, Alastair Houghton
 wrote:
> On 29 Apr 2009, at 11:44, Kyle Sluder wrote:
>
>> On Wed, Apr 29, 2009 at 6:00 AM, Alastair Houghton
>>  wrote:
>>>
>>> But all of this is somewhat academic in a way, because Apple has handily
>>> provided NSOperationQueue for you which is probably what you should be
>>> using
>>> unless you have some backwards compatibility requirement or some other
>>> requirement that NSOperationQueue doesn't satisfy.
>>
>> NSOperationQueue is broken:
>> http://www.mikeash.com/?page=pyblog/dont-use-nsoperationqueue.html
>
> Yes, it is, though I was under the impression that not everyone was seeing
> problems with it.  However, given the simpler sample program Mike put in the
> comments, it does look pretty borked to me.

It appears that the reason not everybody can reproduce the problem is
because the bug is hardware-dependent. Thus this fact won't save you
unless your code won't ever escape your machine (or 10.5.7 fixes it,
or you only support 10.6 and that fixes it).

> Anyway, there's always
>
> 
>
> (for instance).

Note that although this is of course the best code ever (ahem) it is
not equally capable compared to NSOperationQueue. (It mostly does
less, but has some extra capabilities as well.) However for what the
poster is after it's probably a good fit, since it's basically a fancy
worker thread.

Mike
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSRunLoop vs. NSThread sleep

[Alastair Houghton]

On 29 Apr 2009, at 11:44, Kyle Sluder wrote:


On Wed, Apr 29, 2009 at 6:00 AM, Alastair Houghton
 wrote:
But all of this is somewhat academic in a way, because Apple has  
handily
provided NSOperationQueue for you which is probably what you should  
be using
unless you have some backwards compatibility requirement or some  
other

requirement that NSOperationQueue doesn't satisfy.


NSOperationQueue is broken:
http://www.mikeash.com/?page=pyblog/dont-use-nsoperationqueue.html


Yes, it is, though I was under the impression that not everyone was  
seeing problems with it.  However, given the simpler sample program  
Mike put in the comments, it does look pretty borked to me.


Anyway, there's always




(for instance).

Kind regards,

Alastair.

--
http://alastairs-place.net



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSRunLoop vs. NSThread sleep

[Kyle Sluder]

On Wed, Apr 29, 2009 at 6:00 AM, Alastair Houghton
 wrote:
> But all of this is somewhat academic in a way, because Apple has handily
> provided NSOperationQueue for you which is probably what you should be using
> unless you have some backwards compatibility requirement or some other
> requirement that NSOperationQueue doesn't satisfy.

NSOperationQueue is broken:
http://www.mikeash.com/?page=pyblog/dont-use-nsoperationqueue.html

I am not under NDA at the moment, so I'll point out that 10.5.7 is
rumored to have fixes for NSOperationQueue.  If that bears out to be
true, then by all means run with NSOperationQueue.  If not, you might
want to hold off until Snow Leopard -- it wouldn't be the first time
that Apple engineers (or anyone else, for that matter) have tackled a
bug but missed some corner cases until the next major release.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSRunLoop vs. NSThread sleep

[Alastair Houghton]

On 29 Apr 2009, at 00:57, Eric Hermanson wrote:

When implementing the while-loop in the main function of an  
NSThread, is it correct to assume it is more efficient on the  
operating system to run the current run-loop until a specified date  
rather than just use NSThread sleepUntilDate to obtain the delay?


If you're talking about a secondary thread, NSThread's -sleepUntilDate  
is probably better.  But you don't even need to use that; you could  
use sleep() or nanosleep() or even select().


However...

 I ask because I don't really need a formal run loop or special  
input source as I'm just checking a shared queue for data (and the  
delay is to allow the thread to gracefully exit).


...you shouldn't be polling your shared queue, *unless* you have some  
real-time requirement that necessitates that architecture, *or* you're  
certain that, for the entire lifetime of your thread, the chances are  
that the queue will always be full by the time the thread gets to  
check it.  If you aren't sure you need to poll, you probably don't  
want to be polling.


What you should be doing instead is either using a semaphore or an  
NSConditionLock to set things up such that your thread doesn't run at  
all unless there's work to do.


 So it's simpler to code just the NSThread sleep, however, I am  
guessing that will cause me context switching performance issues and  
I'd be better off using the NSRunLoop?


If the NSRunLoop has nothing to do, I imagine it does the same thing  
anyway.


Finally, is it acceptable to use the NSThread's cancelled/ 
isCancelled mechanism to check for the thread-exit hint, rather than  
set/check a global variable in the NSThread threadDictionary (as  
Apple's documentation shows)?


That's what -cancel and -isCancelled are designed for.  That said, if  
I were implementing a thread to managed a work queue (which is what  
you're doing), I'd be inclined to override the default implementations  
so that they added an item to the work queue... that way the thread  
could block on the work queue and would wake up if someone sent - 
cancel to it.


But all of this is somewhat academic in a way, because Apple has  
handily provided NSOperationQueue for you which is probably what you  
should be using unless you have some backwards compatibility  
requirement or some other requirement that NSOperationQueue doesn't  
satisfy.


Kind regards,

Alastair.

--
http://alastairs-place.net



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSRunLoop vs. NSThread sleep

[Eric Hermanson]

Hello,

When implementing the while-loop in the main function of an NSThread,  
is it correct to assume it is more efficient on the operating system  
to run the current run-loop until a specified date rather than just  
use NSThread sleepUntilDate to obtain the delay?  I ask because I  
don't really need a formal run loop or special input source as I'm  
just checking a shared queue for data (and the delay is to allow the  
thread to gracefully exit).  So it's simpler to code just the NSThread  
sleep, however, I am guessing that will cause me context switching  
performance issues and I'd be better off using the NSRunLoop?


Finally, is it acceptable to use the NSThread's cancelled/isCancelled  
mechanism to check for the thread-exit hint, rather than set/check a  
global variable in the NSThread threadDictionary (as Apple's  
documentation shows)?


Thank You,
- Eric


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: When to release an NSThread instance

[Roland King]

if you don't need to reference the thread again you can just release  
it (and the target object used in initWithTarget:selector:object) as  
soon as you've called -(void)start on it. You are correct that the  
thread will exit when the method you are calling finishes and you  
don't need to call exit. When an NSThread is started it retains its  
target object and argument and the thread itself is retained  
presumably by some subsystem which manages threads. When the task is  
complete the target object and argument are released and the NSThread  
is released automatically too. So


MyTargetObject  *target = [ [ MyTargetObject alloc ] init ];
MyArgObject *arg  = [ [ MyArgObject alloc ] init ];

NSThread *t = [ [ NSThread alloc ] initWithTarget:target  
selector:@selector( someMethod: ) object:arg ];

[ t start ];

// in any order you like
[ target release ];
[ arg release ];
[ t release ];

should work fine.


On Mar 7, 2009, at 7:55 AM, Stuart Malin wrote:

I have a main thread method that allocates an NSThread object and  
inits with initWithTarget:selector:object.  I then invoke the NSTask  
instance with -start.


The specified selector is invoked, and there performs a background  
task that takes some time. When it is done, that method invokes a  
callback using  
performSelectorOnMainThread:withObject:waitUntilDone.  That callback  
selector updates the applications U/I to reflect the outcome of the  
background task.


After invoking the callback, the background task method cleans up,  
releases its autorelease pool, and then control reaches the end of  
the method.  I am under the impression that having the method reach  
the end is sufficient to have the thread end. Is that correct? or do  
I need to invoke the thread instance with -exit ?


Big question: how do I release the memory associated with the  
allocated task instance?  I have two notions:


1) have the main thread callback autorelease the thread instance

2) have the thread autorelease itself at the end of the background  
task method after it invokes the callback (which is invokes  
with ...waitUntilDone:YES).


I know I am treading in dangerous waters with threads... but the  
background activity can take many seconds, and I want the U/I  
responsive while the background activity is being performed.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/rols%40rols.org

This email sent to r...@rols.org


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com