From owner-freebsd-hackers Fri Apr 12 04:54:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA27853 for hackers-outgoing; Fri, 12 Apr 1996 04:54:37 -0700 (PDT) Received: from rogerswave.ca (mail.rogerswave.ca [198.231.117.195]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA27848 for ; Fri, 12 Apr 1996 04:54:35 -0700 (PDT) Received: from wong.rogerswave.ca (wong.rogerswave.ca [204.92.17.32]) by rogerswave.ca (8.7.2/8.7.2) with SMTP id HAA02235; Fri, 12 Apr 1996 07:57:58 -0400 (EDT) Date: Fri, 12 Apr 1996 07:41:06 -0400 (EDT) From: Wong To: Terry Lambert cc: terry@lambert.org, hasty@rah.star-gate.com, roell@blah.a.isar.de, hackers@FreeBSD.org, roell@xinside.com Subject: Re: The F_SETOWN problem.. In-Reply-To: <199604111804.LAA04310@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 11 Apr 1996, Terry Lambert wrote: > Sounds like what you want is TQE's with AST's to implement primitive > deadlining (as opposed to implementing real deadlining). That is one way of using AST by some unix box(not just VMS). > > All of the AST mechanisms discussed so far really don't have the > idea of implementing TQE's anywhere in them... even my calls for > kernel one-shots wouldn't make the thread schedulable if there > were other ready-to-run threads (processes) ahead of it in line > that had not consumed their system quantum. > suppose if you have another CPU just wait for that thread and nothing else. i.e. CPU have priority and the kernel is n-queue scheduling and pre-emptive fix priority for process. we don't even need re-entrant kernel. however,thread (OS/2 style) is definitely helping out here. > For what you want, in terms of being able to respond deterministically, > kernel preemption is required. > > Which means kernel reentrancy is required. > > Which means kernel multithreading is required. > > These are all on my list, but they ar a long way off at present, and > much of the required changes are going to have to go in when the > interrupt virtualization goes in for SMP. It's a requirement of > that model that the interrupt service routines be split, and the > absolute minimum amount of work be done at interrupt level, queueing > the actual work for later. This will have the side effect of decreasing > interrupt latency, even in the UP case, since after the queue but > before processing, the system would be reay for another interrupt > (NT does this; so does SVR4 ES/MP and Sequent's OS, as well as Solaris). > I certainly haven't been working on the interrupt code; I've only > been working on the system call entry into the kernel, one of the > three ways in (the third being via exceptions, like page faults or > stack growth). > > I think I've found someone with greater amibitions with shorter time > frames than myself. 8-). actually, if you can recommend me a cheap and good 2-CPU motherboard I might be able to work on it. Ken