Date: Thu, 16 Nov 2000 14:05:07 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: arch@freebsd.org Subject: potentially simpler approach than scheduler activations. Message-ID: <20001116140506.Q830@fw.wintelcom.net>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001116140506.Q830>