[Openmcl-devel] forking to dump?

Hamilton Link helink at sandia.gov
Thu Jul 10 00:48:06 UTC 2008

Gary Byers wrote:
> On Wed, 9 Jul 2008, Hans Hübner wrote:
>> Hi,
>> one of my applications is a web server (it needs to run continously)
>> with a very large in-memory data set.  I can recover the data into a
>> freshly started Lisp from files, but in order to save time, I would
>> like to regularily dump images.  Now, dumping an image takes 1-2
>> minutes and the Lisp exits when it is done, so I thought it might be
> Out of curiousity, how large is the image ?
>> an option to duplicate the running process by forking, then dump the
>> image in the child process.  I did some experiments, but my naive
>> attempts do not work:
>> (when (zerop (#_fork))
>>  (ccl:save-application "teh-dump"))
>> It appears as if SAVE-APPLICATION does work at all in the child
>> process - it just seems to exit having done nothing.
>> Is there some way how this can be made to work?  In principle, fork
>> should create a process with the same memory layout as the parent
>> process, but propably there are issues with threads that one needs to
>> handle?

[..GB magic elided...]

> I tried that and it happened to work on FreeBSD, but the environment
> in which the child finds itself - where all of the other threads that
> claim to be there aren't really there, even if they hold locks -
> offers lots of ways to lose.  (It offers even more ways to lose
> on Darwin, where Mach-level exception handling isn't set up in
> the child process.)

Wow, I had _no_ idea this was even remotely possible, Gary.  Am I 
correct in understanding that you managed to save-application without 
quitting all of lisp (by merit of forking off a duplicate lisp 
environment first)?  Last time I talked to you about why save-app quit 
lisp, it had to quit in order that the image-dumping code didn't need to 
contend with the garbage collector or other threads while it was writing 
the new image file.  Does fork work some magic to avoid these issues 
while forking the copy, or was this not as big a deal as I thought?


More information about the Openmcl-devel mailing list