Re: More thread scheduling observations
Re: More thread scheduling observations
- Subject: Re: More thread scheduling observations
- From: Kurt Revis <email@hidden>
- Date: Sat, 4 May 2002 12:13:55 -0700
On Saturday, May 4, 2002, at 11:41 AM, Andy Bull wrote:
THREAD_PRECEDENCE_POLICY
In my feeder thread, I start an ordinary NSThread and in it I
execute the code below, so far I've had no detectable dropouts with
this priority setting (on a b/w g3 400 and new iMac 800) even if I
resize and move windows for a minute or two. Original priority of the
thread is normally 31, increased to 64 (or even around 50) it seems
good. But I must say that I do not know what real effect on the rest of
the system this has or even if this is kosha code! Any comments are
welcome ...
[code using pthread_setschedparam]
Looks OK to me. From what I can figure out from wading through the
pthread and kernel code, it looks like what I'm doing (using the Mach
thread API) and what you're doing (using the pthreads API) end up having
the same effect. At least in the most general of terms... they take
quite different routes and there are undoubtedly lots of subtleties in
the kernel that I don't know about.
BTW, on my machine, I have to create a big window (probably 1000 pixels
square) and drag it around without any pausing in order to get
dropouts. I can also see the CPU Monitor in my dock stop updating...
that's how I can tell if I'm dragging consistently enough or not. I'm
not worried so much about this particular situation (it's pretty
pathological) so much as exploiting it because it's really easy to do.
--
Kurt Revis
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.