Anthony Worrall (Anthony.Worrall@reading.ac.uk) wrote:
> With the advent of unix based multi-processor machines and (hopefully :->) a
> standard interface to threads are there any plans for pop11 processes to be
> implemented as threads?
Can you say "dlocal" :-?
The reason Poplog processes are relatively slow to swap is because
the stack frame has to be checked for dynamic localisations. And
no threads package supports that concept. If a threads package
properly supported exceptions you might be able to hack something
up - by copying the process & raising an exception (ick, ick!).
However, you *still* need to be able to intercept process swapping
because of Type-3 variables. This is the "well-known" defect in
Poplog's implementation of processes. To quote from REF PROCESS
| (At least, this should be the case. Currently, the system is
| deficient in that type-3 local lexical variables of procedures forming a
| process are not copied, and may therefore give rise to unwanted
| interactions between the copy and the original in programs using these
| (see REF *VMCODE for a description of type-3 lvars); this bug will be
| fixed in a future release of the system. Another current bug is that
[The other current bug I leave you to read for yourselves. However,
you may never wish to use processes ever again if you do!]
When this bug is corrected, it will require the compiler to copy the
IDENT of Type-3 lexicals at various stages and save and restore them
differently. This will not be supported by threads.
Note that Scheme solves this problem (with respect to call/cc) rather
differently. All (assignable) variables are Type-3 and none are
copied.
So although I'm not a developer of Poplog, I think there is good reason
to doubt that threads and Poplog processes will ever be compatible. But
perhaps, just perhaps, the C++ people will really, really surprise us and
add dynamic localisation to threads. No holding your breath, now.
Steve
|