[Openmcl-devel] process-run-function and mach ports usage

[Gary Byers]

A free copy of the next version of CCL to the first person who can
answer the question:

"What OS introduced/popularized the concept of memory overcommit ?"

Hint: it wasn't Solaris.  Sun used to (and perhaps still does)
publish papers arguing against the practice.

On Thu, 24 Feb 2011, Daniel Weinreb wrote:

> My current favorite item of brain damage in Linux:
> 
> http://opsmonkey.blogspot.com/2007/01/linux-memory-overcommit.html
> 
> You ask Linux for memory.? It says, sure, here's your memory.
> Then you make the mistake of actually trying to USE it,
> and you get an error from Linux.
> 
> CCL does not like this, as we have discovered in practice.
> 
> In theory, you can turn off this feature.? But it turns out
> that a lot of Linux programs *depend* on it; they allocate
> a lot more than they need.? So if you turned it off, enough
> other Linux programs would fail that it's out of the question.
> 
> There's no cure for this disease.
> 
> -- Dan
> 
> Shannon Spires wrote:
> 
> Wow. This little exchange was a mind-blower. My jaw is hanging open. My naiv
> e, childish illusions of software competence have been dashed.
> 
> If bridges were built with this level of professionalism, people would die a
> nd engineers would be jailed.
> 
> I've heard that "the difference between a Porsche and a Ferrari is that the 
> Porsche was designed by people who went to college." All this time, I had so
> rt of assumed
> Porsche:Ferrari :: Apple:Microsoft.
> 
> Guess not. 
> 
> It's time somebody wrote an operating system with the same degree of enginee
> ring rigor that Germans use to design cars. Are we yet tired enough of this 
> kind of crap to do something about it?
> 
> 
> [Gary wrote:]
>
> 
> 
> Apple's documentation for mach_thread_self() (see
> 
> <http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/osfmk/man/mach_thr
> ead_self.html?txt>)
> 
> doesn't seem to explicitly state that that function increments the
> port's send reference count (though it certainly seems to.)  The GNU
> Hurd documentation does state this, but warns the user that
> mach_thread_self() allows the reference count to silently wrap around
> (wrap around 2^32 ?  what ?) without error and that the reference count
> shouldn't be decremented if this overrun might have happened.
> 
> This stuff escaped from a lab somewhere; the fact that it's been
> lurching around the countryside frightening villagers as long as it
> has is pretty sad.
> 
> I don't care what a thread's Mach port's send right's reference count
> is.  I do care that thread creation doesn't leak kernel resources, and
> because if this nonsense it does.
>
> 
> 
> [then mikel evins wrote:]
>
> 
> 
> However, during the investigation, we ended up talking over the issues with 
> Avie Tevanian, who was the boss of that stuff at NeXT at that time, and who 
> was before that involved in the design and construction of Mach at CMU. What
>  struck me about the conversations was that Avie said Mach was designed to l
> eak certain resources because allowing them to leak avoided some costly hous
> keeping, and in "normal use" the leaks would not be a problem. Mach's design
> ers simply assumed that systems would be rebooted often enough to prevent an
> y issues arising.
> 
> I remember that he seemed slightly put out that NeXT customers would use sys
> tem calls in a way that violated that assumption.
> 
> 
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
> 
> 
> 
>