Date: Tue, 22 Apr 1997 10:02:12 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: james@westongold.com (James Mansion) Cc: terry@lambert.org, freebsd-hackers@freebsd.org Subject: Re: Price of FreeBSD (was On Holy Wars...) Message-ID: <199704221702.KAA26548@phaeton.artisoft.com> In-Reply-To: <335C7EB6.7E62@westongold.com> from "James Mansion" at Apr 22, 97 10:02:46 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > Microkernel systems can be as efficient as monolithic ones. Modularity > > > > > > Name one. The very requirement of the boundaries will introduce a cost > > > that you could avoid with a direct function call. > > > > Chorus; it does not enforce protection domains between OS servers and > > the OS, only between the OS & OS servers and user space. > > So? Are you saying that the executing thread calls directly between the > servers, like (say) a call to an in-proc COM server? Yes. Without the idiotic "free thread marshaller" imposed by the misdesign of the virtual memory system in NT/95. [ ... direct call and/or vtable instruction fixup call ... ] > or: [ ... indirect call through marshalling interface ... ] > Perhaps simplified somewhat. I'll grant you that if the monolithic > kernel has to hand over control to kernel internal threads then you > get it all back, but that's essentially a case of a Chorus-like MK > design with the server running internally. You don't need to do the marshalling if you are in the same VM space; the NT/95 "free threading" model is actually broken in this regard because of a design issue in the VM/"Viper" framework interaction. It's not something they are going to be able to change easily because it touches on historical handling of process address spaces for non-threaded processes. They might have been able to do it if they required free-threaded COM modules to have specific section coloring for the shared data regions, and the virtual construction had to take place into a seperate heap region with the same (shared) attributes. But now they are doomed to an eternity of free-thread marshalling because of their treatment of object instantiation vis-a-vis thread local storage. Pity, that. > Clearly if you allow a thread to carry its execution directly into a > server and to hop between them then you remove the overhead, but my > understanding of the terminology is that one expects and MK 'server' > to be an executing entity rather than a DLL. "Server" or "Service"? Even in the MS case, a not-in-process server running on the local machine does not have to have free thread marchalling for "Apartment" or "Rental" model threading... and then that's exactly what the threads are doing: moving into the other code. The "Free Threading" case is a mistaken process address space implementation on MS's part; your heap is your heap. Chorus doesn't really follow the MACH "server" model terribly closely (that's why it's fast). The point of having a "server" rather than a "service" is to provide an execution context in the seperate protection domain on which the request may be serviced... no protection domain, no seperate execution context. I don't know what happened to them after I left Novell, but there was some success reported in porting UnixWare and NetWare to run on a common Chorus kernel and set of services. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704221702.KAA26548>