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

[Gabriel Dos Reis]

Hi Gary,

Thanks for elaborating on the "save image" model behind CCL.  That clarifies
certain things for me a lot.  Many thanks.

[...]

> ;; We might say that there's a "static" binding of *x* to 1.
> (defvar *x* 1)
>
>
> ;; In the listener thread
> (let* ((*x* 17)) ; a dynamic binding of *x* to 17
>  (save-application "x-is-17.image"))
>
> ;; By the time SAVE-APPLICATION actually gets around to writing the image.
> ;; the listener thread will be dead; as it dies, it disestablishes its ;;
> dynamic bindings.
>
> $ ccl-or-ccl64-its-so-confusing -I x-is-17.image
> Welcome to whatever version this is!
> ? *x*
> 1

given the model you just explain,I think I understand the choices
that CCL made.  Thanks.  See below for more comments.

> It's true that some lisp PROCESS objects persist across
> SAVE-APPLICATION; I think that this is true of the value of
> *INITIAL-PROCESS* and it's also true of the value of some variable
> that refers to the initial listener process.  That allows us to say
> things like "this thread-local hash table is owned by the initial
> listener" and have that ownership persist, but nothing "under the
> hood" of that PROCESS object really persists: there's a new OS-level
> thread involved, with stacks whose size/location/content all likely
> differ and whose dynamic bindings and other aspects are only
> coincidentally similar.

I see.  I also tried to use CCL's specific "DEFSTATIC" to work around
the issue, but I was unsuccessful.

> Dynamic bindings aren't saved in the image; the binding (the association
> between a variable and a value) is thread-local, and the dynamic state
> of threads (a) doesn't exist when the image is written and (b) therefore
> isn't written to the image.
>
> This has never worked differently in CCL.  (I would know if it had.
>  Honest.)

I am not doubting you.  All I can tell you is that the application works pretty
well with CCL-1.4 and onwards except recent CCL-1.7-dev  Unfortunately,
I did not record the SVN revision before making the update.  I tried bissection
but the trunk seems to be unbuildable on x86-64 for a long time, so my
efforts were non-conclusive.

> If the example above had been written as:
>
> (setq *x* 17) ; modify the static binding
>
> (save-application ...)
>
> then that modification would persist.

Yes, these forms -- assignments at toplevel -- work pretty
well.  What is happening in my application is the following:
   1. I have a set of fasls containing toplevel assignments
       like above

   2.  I use a function to LOAD those fasls.  After loading, I verify
        that the special variables have the "right" (modified)
        value.  Then I call SAVE-APPLICATION.

   3. The saved image from step 2. does not appear to have the
       correct (modified) values for the special values.  These seem
       to contain only their original toplevel values before the LOAD.

   4.  The only LET-binding in effect while loading the fasls is
        that of *PACKAGE*.  No other LET-binding (or the like) is in effect.
        Am I understanding you correctly that by the time SAVE-APPLICATION
        does it works, the *PACKAGE* has been "unwound" to its previous
        value, so any changes to its symbols are lost?
        I did not suspect this because other Lisps which have dynamic bindings
        per thread did not bark at this (nor did CCL-1.4.)

-- Gaby