Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!k.gp.cs.cmu.edu!dandb
From: dandb@k.gp.cs.cmu.edu (Dean Rubine)
Newsgroups: comp.sys.next
Subject: Re: NeXT and Real-Time
Keywords: real time music mach ualarm paging operating system
Message-ID: <8207@pt.cs.cmu.edu>
Date: 27 Feb 90 21:09:51 GMT
References: <8196@pt.cs.cmu.edu> <2285@quiche.cs.mcgill.ca>
Organization: Carnegie-Mellon University, CS/RI
Lines: 37

>In article <8196@pt.cs.cmu.edu> jcd@maps.cs.cmu.edu (Jean-Christophe Dhellemmes) writes:
>>I tried to use ualarm(3) to execute a function every millisecond (ualarm let
>>you set up any interval between 1 and ~65000 microsecond) and found out that
>>the NeXT machine can't keep up with that speed and that for any interval
>>smaller than ~65000 (the max, i.e. 65 ms)

In article <2285@quiche.cs.mcgill.ca> clement@quiche.cs.mcgill.ca (Clement PELLERIN) writes:
>An unsigned is 32bits on the NeXT.
>You can go up to 4 billion if you want, not just 64K.
>I tried a sample program and I could easily get signals
>at 1 second intervals.

    You're right to point out his mistake, but you've not helped him with his
problem at all.  He wants to get short intervals, not long ones.  I've had
success using DPSAddTimedEntry to get a function called every 20 msec.
I haven't tried shorter times.  Unfortunately, the only time the function
gets called is when your process is waiting for input, i.e., these calls
do not interrupt computation.

   For true real time control, you need at least the ability to bound response
time to external events.  For NeXT/Mach, presumably you'd want user level
(not kernel) programs to operate in real-time, since this makes it possible
for mere mortals to create such programs.  This would mean the ability to lock
a process in physical memory (since page faults must be avoided), to raise
a process's priority so that it cannot be preempted, and to guarantee the time
it takes to resume a process in response to some event (e.g. process X is
guaranteed to be called within .5msec of such-and-such interrupt).  All these
things likely require pretty intensive Mach modifications, which is probably
why they're not available (yet?), though I find the lack pretty inexcusable
on NeXT's part.  Like JCD points out, this makes the Amiga preferable for doing
true real-time control work.

-- 
ARPA:       Dean.Rubine@CS.CMU.EDU	
PHONE:	    412-268-2613		[ Free if you call from work ]
US MAIL:    Computer Science Dept / Carnegie Mellon U / Pittsburgh PA 15213
DISCLAIMER: My employer wishes I would stop posting and do some work.