Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!steinmetz!vdsvax!barnett From: barnett@vdsvax.steinmetz.UUCP (Bruce G Barnett) Newsgroups: comp.unix.questions Subject: Re: Real time Unix Message-ID: <2340@vdsvax.steinmetz.UUCP> Date: Mon, 24-Aug-87 09:27:12 EDT Article-I.D.: vdsvax.2340 Posted: Mon Aug 24 09:27:12 1987 Date-Received: Tue, 25-Aug-87 05:31:48 EDT References: <1065@vu-vlsi.UUCP> <253@etn-rad.UUCP> <2862@psuvax1.psu.edu> <8102@mimsy.UUCP> Reply-To: barnett@steinmetz.UUCP (Bruce G Barnett) Distribution: na Organization: General Electric CRD, Schenectady, NY Lines: 29 I have always heard that Unix isn't real time because: If a real-time event causes a change in priorities and scheduling while a system call was executing, the system call won't be interrupted. That is, the system does not reschedule in the middle of a system call, and the potential delay for an urgent real-time event is equal to the length of time of the longest system call. I am not talking about interrupts, but a change in priorities as a result of a real-time event ( i.e. the device driver handling an interrupt). I have believed, but never implemented, that if you need fast response you do it in the device driver. If necessary, you can write a pseudo-device driver, and bind it into the kernal. This can give you procedures that any process can have access to with the same overhead as a system call. I assume if you can specify which applications, processes, and deamons are running, and give some processes highest priority, you can improve the real time response. So perhaps the question is, do you need fast responses? or real time? Any comments? Has anyone done this? -- Bruce G. Barnett uunet!steinmetz!barnett