On 31/01/2011 06:56 PM, Darren New wrote:

> Linux closes files, deallocates memory, reclaims disk space for unlinked
> files that this process had the last open on, unlocks files, closes the
> file holding the executable code, frees up page maps, and releases
> certain kinds of semaphores. And probably more, nowadays.

Man, I had no idea...

>> I was thinking more that if you get the microcode right, you might
>> physically fry the processor.
>
> Oh. Not in any microcode I've ever seen (not that I've seen much), but I
> imagine it's possible.

Well, since the microcode is just a bunch of extremely wide bitmaps that 
open and close various switches, it wouldn't surprise me if doing so in 
the wrong combination could short-circuit something, or do something 
similarly bad.

OTOH, maybe if the microcode is user-modifyable, you'd design in some 
margin for error...

(Do modern AMD64 processors let you change the microcode? Or is it wired 
in permanently?)

> Because you couldn't have pointers into the middle of segments. The
> memory model was a bunch of "objects" in the sense that they were atomic
> lumps of memory that you could move around without adjusting pointers
> everywhere.

Oh, OK.

> You know how swap space works, right? The page file?
>
> memmap is using the exact same mechanism, except it pages out to the
> file you specify instead of "the swap space".
>
> Or, viewed another way, all of memory is memmapped, and that system call
> lets you pick which file it's memmapped into instead of the default.

So what you're saying is it lets you access a file like you access 
memory? (And presumably avoids the data being swapped out to the swap 
file when you actually want it to end up in some other file anyway...)

>> So... how do you change the size of the file then?
>
> I don't know that you do, if that's how you're accessing it. I haven't
> used it in so long that it's all probably changed by now.

OK.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message