[Prev][Next][Index][Thread]
Re: On introspection of the dynamic environment
Dustin Voss wrote:
> As I was tossing and turning all last night (I couldn't sleep), I got
> to thinking about Functional Developer's approach to threads and
> dynamic environments. It seems a little shallow.
I was very impressed by FD's thread support. It beats Java or C's threads
easily in terms of elegance and integration into the language.
> Don't processes also have a dynamic environment, consisting of non-
> thread-local bindings and running threads?
I think that if you don't define a variable or slot to be a thread
variable or slot, that's where it lives:
define varaible klin = 1; // Process environment
define thread variable blim = 2; // Thread environment
> you cannot retrieve the set of all defined classes, or the set of
> generic
> functions, or the set of top-level variables -- you cannot retrieve the
> set of active bindings at all.
Dylan's introspection is limited in some areas because the trade-offs
between allowing a fully dynamic environment and compiling efficiently
were felt to be too great. The design notes mention that writing a
Meta-Object Protocol in Dylan wasn't seen as a priority compared to
writing code that could compile efficiently.
> I'm not talking about text strings,
> here. Current introspection doesn't require text strings, and I don't
> see why more complete introspection would
I'd actually quite like to be able to get classes and methods by name for
serialization and library support: I've found this useful in Java,
although the linking model is different. Possibly I should just use
format-to-string("%=") on the <type> of an object, or write better
interfaces. :-)
> Similarly, the thread library implemented by Fun'Dev does not allow one
> to obtain a list (or even count) of active threads. Combining thread
> introspection and binding introspection would let one thread dip into
> another thread's local variables and alter them to change its behavior
> (in a well-controlled fashion, one would hope).
Race conditions and deadlock might pale besides the problems that emerged
from mis-use of this, but it makes sense and is a very powerful feature
that I'd certainly use (for object pools, event handlers and server
proxies). FD does already have notifications and thread restarts, which
allow inter-thread control and communication.
> The list of active bindings already exists. The garbage collector
> knows it. You just can't get at it.
I don't know exactly how FD's Garbage collector works, but the graph of
bindings might simply be the heap, with the finalizer called when a block
is freed.
> BTW, the <thread> class is actually a bit of a misnomer. Threads and
> functions execute, classes don't. A <thread> object cannot execute, so
> it isn't a a thread. The class should actually be named <thread-
> identifier> or something.
Java suffers from the same naming problem. I think the rationale is that
the <thread> class contains all the resources neccessary to run a thread:
the native thread reference, the stack, any synchronization resources, the
dynamic environment and the function to run (which is of course an object
in Dylan), so it's reasonable to identify this as a <thread>.
- Rob.
--
Rob Myers - robm@tdv.com The Digital Village - www.tdv.com
MacOS wonderfulness for The Hitch Hiker's Guide to the Galaxy Game.
"Arthur bought the Apple anyway."-So Long & Thanks For All The Fish.
Follow-Ups:
References: