Help with theoretical crazyness, please!

[Kevin Buettner]

On Nov 14,  1:48pm, Brian Cluff wrote:

> Ok, I'm still struggling with these P100 machines that I am trying to run
> Star Office on.  The problem is that under windows SO loads in 1 min or
> less, but it's not stable.  Under linux it takes over 5 min to load, but is
> stable, but by the time it's done loading the class is partially over, so
> it's unacceptable... and no it's not a lack of memory problem.
> 
> Anyway, in a dream last night I though it something that is so sick and
> twisted it might just work, but I don't know how to do it.
> a while ago I heard of a way to "compile" perl programs by causeing a core
> dump and then executing that core dump as a binary executable.   I was
> thinking that if I could do the same thing with SO that I could load the
> whole thing on these slow machines in about 10 seconds.. beating windows by
> a lot.

I remember hearing about this in the past too.  As I recall, there was
also a way to get emacs to dump itself in this fashion too which made
it start up somewhat faster.

I have no idea if this mechanism works on Linux or not, but even if it
does, I seriously doubt it'll work for Star Office.  SO is a
multi-threaded program and, unfortunately, on Linux right now it is
not possible to obtain a truly useful core dump which respresents the
complete state of a multi-threaded program.  Recent kernels will
dump each thread to a separate core file, but, even if you have a
way to restart a core file, this won't end up being useful since
you must make sure that the address space is shared amongst the
various threads that you restart.

Even if the multi-threading problem weren't an issue, the other
potential problem that I see with this approach is that while the core
dump preserves the register and memory state of the process, it
doesn't preserve the state of any file descriptors that the
application might have open.  I have no idea if this would've been a
problem for SO or not...

Kevin