Date: Fri, 8 Jan 1999 23:17:15 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dot@dotat.at (Tony Finch) Cc: hackers@FreeBSD.ORG Subject: Re: pthreads question/problem... Message-ID: <199901082317.QAA19479@usr05.primenet.com> In-Reply-To: <13973.60376.9845.729115@chiark.greenend.org.uk> from "Tony Finch" at Jan 8, 99 11:28:24 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Sometimes you want M to be large relative to the number of CPUs > > > because you are using threading to improve userland IO concurrency. > > > > Finish the thought: > > > > "...and you don't want to use async I/O to improve I/O > > concurrency because, while doing so would be less overhead > > than using a bunch of threads, it doesn't accomplish > > your *real* goal." > > The other reason for not using aio is because the aio calls do not > cover the whole range of system calls that block (open, close, stat, > unlink, etc...). I don't see how you can fix that without either using > some sort of fork or adding stuff to the API. Actually, that's the reason for implementing the POSIX AIO calls as library entry points that make use of async call gates, instead of jamming the things into the poor kernel's overstuffed bowels... the POSIX AIO interface only applies to a subset of calls, and thus is pretty frigging useless. The whole migration to kernel threads has been ill-thought out. From what I can tell so far, the reasoning is so that we can use a precompiled version of glibc.so that makes Linux system calls, instead of compiling our own version of glibc.so that Linux programs use, and which has entry points for the Linux system calls that wrap what are actually FreeBSD system calls instead. The disadvantage of this, of course, is that you need less Linux emulator code in the kernel... (that was me being facaetious). This is a general case of kernel bloat. There's really no topological difference between call conversion threads that can be signal preempted by a user space scheduler, and Linux kernel threads that are preempted by the kernel scheduler. The only real difference is SMP scalability (which isn't resolved in the least by Linux kernel threaded applications that have any technical reason to be implemented as threaded instead of as seperate processes), and that requires user space cooperation and a lot of scheduler work unrelated to Linux kernel threads. Put another way, changing the saving the registers and changing the stack and the program counter is the same whether it occur in user or kernel space; why people make such a big deal about where this happens is really beyond me; it has to be related to their misunderstanding of rfunctional decomposition a part of the problem solving process.... It seems to me that this is nothing more than additional kernel bloat whose sole purpose is to enable FreeBSD to run Linux code that depends on static linking or unrecompiled Linux shared libraries, which is of dubious value at best. >From that perspective, it would be a hell of a lot more valuable to do Solaris kernel threads emulation, and get 1000 times as many applications (including a JAVA, a JDK, an a SWING and AWT implementation that doesn't require paying Sun $500,000 (or whatever) to actually use in real life). You could also approach Solaris the same way: provide a FreeBSD system call calling version of a libc.so that looks like Solaris binaries expect it to look. The additional advantage of this is that you would no longer need a Solaris license to run Solaris binaries on FreeBSD (which is a good reason to install Solaris instead of FreeBSD,since you're paying for Solaris anyway). Even better would be to replace the FreeBSD manifest constants, as necessary, to bring the FreeBSD ABI into line with the Solaris ABI, so that code will "just run". The only real remaining question is whether I namelist and document the Solaris libraries, and someone else implements them, or vice versa (I'd prefer vice versa, since then "someone else" can be in Germany and thus beyond any legal reproach, and implementation could use help and scales to more people more easily...). The manifest constants in the headers are, of course, published, regardless of what the license claims, at least for anyone in the jurisdiction of the US 5th circuit court of appeals. Since that doesn't stop them from suing, it would be nice if a German could look at documenting them, too. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901082317.QAA19479>