From owner-freebsd-arch Thu Nov 16 14: 5:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 5586E37B479 for ; Thu, 16 Nov 2000 14:05:08 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAGM58w16060 for arch@freebsd.org; Thu, 16 Nov 2000 14:05:08 -0800 (PST) Date: Thu, 16 Nov 2000 14:05:07 -0800 From: Alfred Perlstein To: arch@freebsd.org Subject: potentially simpler approach than scheduler activations. Message-ID: <20001116140506.Q830@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is an idea that I hope doesn't generate any major bikesheds, I just wanted to toss it out as something that someone might want to research further and possibly complete it. It's an idea to make the uthreads library safe against disk IO blocking the entire process. ====== We could have a pretty good threading system with some minor tweaks instead of rewriting the proc/scheduler mechanism. Afaik we still have problems with: a) sysV IPC b) disk I/O c) page not preset faults making the entire thread library block Solutions: a) implement kevent filters for messsage queues and semphore sets relatively easy. b) make uthreads use aio for disk files, relatively easy c) use a syscall that requests that on a page not present but valid pagefault we generate a signal such as SIGPNP (?) and have the kernel async page it in handing the process a kevent with the void * pointer referencing the page that was faulted in async. Or, have an aio call that the scheduler will call to have the page filled in. I know it's not exactly what you want, but it seems that it would be a lot easier to implement and at the same time a lot safer for the kernel. I know that by applying these band-aids we aren't completely solving every problem and as new interfaces pop-up we might have to apply more band-aids to libc_r, but I think this might get us past the point of system that breaks down on disk IO. We could then later use rfork threads and a "big giant" over the uthread schedule to take advantage of multiple processors. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message