[movitz-devel] Re: yield stuff in threads.lisp

[Frode Vatvedt Fjeld]

So, the SO is visiting the dentist, the little brat has been sleeping
for an hour or two, and I've allowed myself half a day off from
working on the new house, and jupiter and mars are properly aligned
with the moon, etc..  so I've been able to work an hour or so on
movitz' threading:

It turned out the problem wasn't really related to the threads as
such, rather it was the REPL and readling code that didn't respond so
well to the default environment that a fresh thread gets set up
with. Now I've debugged and robustified this code somewhat, and this
should make testing threading:yield etc. work ok.

Here's an illustrative screenshot from a bochs session, with
line-numbers added for references below:

                           
 1  INIT> :pa threading
 2  THREADING> (+ 35 7)
 3  #x2a
 4  THREADING> (yield (make-instance 'thread))
 5  [0d] INIT> *
 6  NIL
 7  [0d] INIT> :bt
 8   <1 (THREADING::STACK-BOOTSTRAPPER ...)
 9  [0d] INIT> (/ 17 2)
10  #x11/2
11  [0d] INIT> (setf *t2* (current-run-time-context))
12  #<THREAD  @ #xf0176>
13  [0d] INIT> (setf *t1* (%lispval-object 6))
14  #<RUN-TIME-CONTEXT :INIT @ #x6>
15  [0d] INIT> (yield *t1*)
16  NIL
17  THREADING> *
18  NIL
19  THREADING> ***
20  #x2a
21  THREADING> (yield init::*t2*)
22  NIL
23  [0d] INIT> ***
24  #x11/2
25  [0d] INIT>


Line 4 is the most interesting one: It first makes a new thread, and
immediately switches control to it. Line 5 is from inside this new
thread, and you can see e.g. that it's getting a default *package*
bound to the INIT package. In line 7 a (short) stack backtrace is
printed for the new thread.  In line 11 the variable *t2* is set to
the new thread object (i.e. the object returned by make-instance in
line 4), which is available through the current-run-time-context
operator which returns the run-time-context that is currently
active. Note that a the threading:thread class is a specialization of
the muerte:run-time-context class. In line 13 the variable *t1* is set
to the initial boot-up "thread", which is not a threading:thread but
just a mere muerte:run-time-context instance. This object is always at
located at the very start of the address-space under the current
image-dumping scheme for LOS0. (6 is the low-tag for such objects.)

In line 15 control is switched back to the original "thread". Line 16
is actually the print-out of the return-value of the functon-call in
line 4. (Note that the yield at line 15 would accept an optional
second argument that would be this return-value.) Line 19 shows that
the *** variable of the initial thread is bound to the value from line
3, and that none of the goings-on in the other thread (lines 5-15)
affected such local bindings. In line 21 control is once more switch
back to the new thread, and we see that there are indeed two separate
environments.

Beware that GC is unlikely to behave robustly in the presence of
multiple thread objects yet (I'm not really sure, but I can't remember
working much on it, so..)

-- 
Frode Vatvedt Fjeld