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

[Daniel Weinreb]

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 naive, childish illusions of software competence have been dashed.
>
> If bridges were built with this level of professionalism, people would die and 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 sort of assumed
> Porsche:Ferrari :: Apple:Microsoft.
>
> Guess not. 
>
> It's time somebody wrote an operating system with the same degree of engineering 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_thread_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 leak certain resources because allowing them to leak avoided some costly houskeeping, and in "normal use" the leaks would not be a problem. Mach's designers simply assumed that systems would be rebooted often enough to prevent any issues arising.
>>
>> I remember that he seemed slightly put out that NeXT customers would use system calls in a way that violated that assumption.
>>     
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20110224/9fe7e576/attachment.htm>