[OT] Re: detecting when an app is beach-balling
[OT] Re: detecting when an app is beach-balling
- Subject: [OT] Re: detecting when an app is beach-balling
- From: Alastair Houghton <email@hidden>
- Date: Tue, 23 Oct 2007 11:49:47 +0100
On 23 Oct 2007, at 03:47, Erik Buck wrote:
Unlike many embedded systems, all Mac OS X threads are preemptively
scheduled. That effectively means that no thread can monopolize
the CPU. All threads are periodically suspended/preempted so that
other threads can run. Watch dog timers are generally not involved.
Except in as much as the preemption is generally performed by way of
a hardware interrupt from a system timer of some description.
There are standard Unix real-time extensions: Functions like rtprio
() enable you to set the relative
priority of threads or processes so that they will be preempted
less or more.
FYI, OS X has:
nice()
setpriority()
pthread_get/setschedparam()
pthread_attr_get/setschedparam()
pthread_attr_get/setschedpolicy()
Various Mach calls
Not to mention, since this is after all the Cocoa developer list,
NSThread's +setThreadPriority: method.
There are also POSIX processor sets (pset_create()) that enable you
to specify which threads can run on which processors in multi-
processor systems. If you disable interrupts on a processor and
set up a system so that the only thread that can run on the
particular processor (or core) is your thread, your thread will not
be preempted. That is the only way to solve hard real time
problems on a Unix system.
Well it rather depends on the problem, the system, and what you
consider to be acceptable failure modes. A number of tasks that used
to be regarded as hard real-time (audio, for instance) are now
generally held to be soft real-time because the performance of
systems has increased so much that the maximum likely delay is now
acceptable whereas previously it wouldn't have been. There are also
special features in some systems (LynxOS being perhaps the primary
example) to enable hard real-time performance.
I believe the Mac OS X window server periodically sends events to
the event queue of all applications
that have a connection to the window server. If an application
does not remove the event from its queue, the window server changes
the cursor to the beach ball automatically. The only thing the
beach ball means is that an application is not taking events out of
its queue fast enough.
Indeed.
From an application's perspective, the Unix select() function is
presumably called from the run loop and used to block the calling
thread unless at least one input source (included in the select()
call) has pending input. The window server's event queue is just
one input source for select(). Timers,
distributed messages, apple events, distributed notifications, and
any file descriptors you add are
included in the select().
AFAIK run loops are built on Mach messaging primitives, not UNIX
select(), at least on Mac OS X. select() certainly used to be used
by X11 apps, though there are other mechanisms in modern UNIXen such
as kqueue()/kevent().
However, all of this (aside from NSThread's +setThreadPriority:) is
heading off-topic.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden