[Prev][Next][Index][Thread]

On introspection of the dynamic environment

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.

Threads have a dynamic environment specific to each thread, consisting
of language constructs such as blocks, handlers, exit procedures, and
thread-local bindings.  I believe that concept should be extended.
Don't processes also have a dynamic environment, consisting of non-
thread-local bindings and running threads?

The dynamic environment remains more-or-less undefined.  A program
cannot fully introspect itself.  Dylan does allows you to retrieve
methods on a generic function and iterate over active handlers, but 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.  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

One might argue that a list of active bindings is useless; I disagree.
Such a list would be great when tracking down a dangling reference to a
DLL, or creating a manifest from a tangled web of references, or when
debugging via trace statements.

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).

The list of active bindings already exists.  The garbage collector
knows it.  You just can't get at it.  One way to achieve full
introspection is to expose the program's dynamic environment to the
program.  The obvious way to do it is through classes like these:

----------------------------------------------------------
define class <dynamic-environment> (<object>)
  slot bindings; // The active non-thread-local bindings
                 // (including let and anonymous bindings)
  slot threads;  // The active threads
end class;

define class <thread-environment> (<object>)
  slot thread-function;
  slot thread-local-bindings;
  slot active-handlers;
  slot exit-functions;
  slot state;
end class;
----------------------------------------------------------

<dynamic-environment> would be a singleton with virtual slots that
change from moment to moment to reflect the application's state.  This
neatly fills the holes in introspection.

It's not perfect, of course.  If two threads want to read or modify the
dynamic environment, that'll cause trouble.  Normally, you'd just lock
the resource in question (in this case, the <dynamic-environment>
singleton).  But the dynamic environment will continue to change
regardless of what you lock.  Especially if it includes lock
information!  Either <dynamic-environment> cannot be locked (which
makes it useless) or it does not always accurately reflect the actual
dynamic environment.  A call to synchronize-side-effects() might
resolve the latter concern.

In another approach, an instance of <dynamic-environment> could merely
be a snapshot of the dynamic environment at the moment of
instantiation.  That would make it more like a traditional (and
predictable) class -- specifically, a read-only class.  Any
modifications to the dynamic environment would have to be performed by
functions that don't operate on <dynamic-environment>.  This solution
is less flexible than the other one, but easier.

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.

So, anyway, that's the product of a restless night.  Enjoy!

--
A.K.A. d_voss@mindspring.net
       dvoss@xypoint.com
Welcome to account Madness!


Sent via Deja.com http://www.deja.com/
Before you buy.
Follow-Ups: