[Openmcl-devel] *initial-process* and *current-process*

[Gabriel Dos Reis]

On Thu, Jun 23, 2011 at 12:42 AM, Gary Byers <gb at clozure.com> wrote:
> On Wed, 22 Jun 2011, Gabriel Dos Reis wrote:
>
>> Hi,
>>
>> I have an application where when I use ccl:save-application,
>> CCL  apparently saves the "old image" (not what I want), that is the image
>> as it was before I LOAD some fasls instead of the "current image" that
>> contains
>> the loaded fasls.  I started seeing that behavior only with "recent"
>> versions of CCL --
>
> I have no idea how SAVE-APPLICATION would do this.  How would it know
> what was part of the "old image" and what wasn't ?

It could be looking at argv[0] in a special way :-)  I dunno, which is
why I was asking.
(Some Lisps such as CLisp and GCL interpret argv[0] specially.)

>
> There are some scenarios where SAVE-APPLICATION could start to write
> an image file and encounter some sort of catastrophic error (out of
> disk space, memory corruption, a bug) before finishing.  The last
> thing written to an image file is signature information that the image
> loader uses to validate the file; an incomplete image file
> can't be loaded.

Thanks. That scenario does not seem to be what is happening in my case.
I tried (most part of the night) to reduce the situation to a simple
reproducible case,
but failed so far.

> You might want to check pathnames and file write dates carefully;
> I don't think it's likely  that what you think is happening is happening,
> and it seems much more likely that there's a more mundane explanation
> for what you're seeing.

I am saving the application in a directory different from the one containing
the original image.  I print the state the objects I interested in right before
SAVE-APPLICATION (they have the right updated values.) When I print
the same objects right after resuming the saved image, they have the old
values before modification and saving.

>> that is anything but recent CCL from trunk works fine.
>
> I think that you'll find that recent versions of the trunk also work
> fine and that you're misunderstanding what you're seeing.

that is possible; I'm still investigating.
Everything works fine with the Windows image available from SVN.
However, it fails on linux 64-bit and I did not introduce anything
platform specific when saving.

>> That led me to wonder the difference between *INITIAL-PROCESS* and
>> *CURRENT-PROCESS*.  Thanks,
>
> As it's used in the names of these variables, the word "process"
> essentially means "thread" or "lightweight process".  The initial
> process (the lisp process/thread that's the value of
> *INITIAL-PROCESS*) was created by the OS when the application started,
> and (as David Rager said) each thread has its own dynamic binding of
> *CURRENT-PROCESS* that refers to itself.

Thanks to both of you.
The objects I am interested in are bound to dynamic variables.  Is it
at all possible
that a separate thread  is performing SAVE-APPLICATION and therefore
is seeing different different values of the dynamic variables?

Thanks,

-- Gaby