Shehzan
Shehzan

Reputation: 287

Cocoa NSApplication Threading Model

Hi I am a newbie to cocoa framework so needed help in understanding the framework better.

My current focus area is to learn about the number of threads the NSApplication creates by default and methods to control it or limit it. i.e., I saw basic NSApplication which created an empty window had created 6 threads and utilizing it. I wanted to get some insights about the following.

1) Is there any method to limit the number of threads? 2) By default the NSApplication makes use of GCD (Grand Central Dispatch) is there any way to disable it?

I am in search for these questions because I want to implement my own threading model from scratch...

And I do know that GCD is more efficient and does the thread management for me. I am just experimenting and want to know.

So please share some insight or point me in the right direction. Thanks in advance

Upvotes: 0

Views: 497

Answers (1)

ipmcc
ipmcc

Reputation: 29946

You asked:

Is there any method to limit the number of threads?

From the context of your question, I assume you mean, "Is there any method to limit the number of threads used by AppKit?", and the answer is effectively, "no." By using AppKit at all, you are implicitly accepting whatever threading model it wants to use behind the scenes. It's a black box. Certainly it's physically possible to write a single threaded executable on OS X (i.e. a command line tool), but displaying any kind of meaningful GUI on OS X without using AppKit is going to be a lot of work.

By default the NSApplication makes use of GCD (Grand Central Dispatch) is there any way to disable it?

Again, no. Same reasons.

I want to implement my own threading model from scratch...

This is a slight over simplification, but the threading model is, to a certain degree, dictated by the OS. Anything you wrote that used mach threads (upon which pthreads are based, upon which GCD is based, etc.) would not be 'implementing your own threading model', it'd be the same threading model that everyone else uses. Likewise, (on OS X) if you aren't ultimately using mach threads, there's no way for you to start a truly concurrent thread of execution in the same process (because only the kernel can do that), so at the end of the day you would be implementing a cooperative multitasking system (that would only ever be able to run on one core) or forking multiple processes and using shared memory or something to coordinate between them (and if you do that, you're still effectively using mach threads, they're just in different processes created by the kernel.)

If you want to tinker with your own thread pool implementation, just do it, and ignore AppKit's background threads. In any AppKit application the main thread is always "special", so you'll also have to ignore that fact, but if it's a thread pool you want to write, don't let whatever AppKit is doing distract you.

If you genuinely want to tinker with the underlying threading model, you'd be better off finding yourself an academic/research operating system (Google around for online University classes on Operating Systems) and tinkering with its kernel scheduler/threading model than trying to re-invent the wheel in a huge, mature, mass-market, security-conscious operating system like OS X.

Upvotes: 2

Related Questions