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

Re: On introspection of the dynamic environment

In article <390808EE.F0391F62@tdv.com>,
  robm@tdv.com wrote:
> 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.

C depends on third-party libraries to provide thread support.  The
situation there is actually similar to Dylan's: neither language was
designed with threads in mind, but later people added support.  But
Java was designed to thread from the get-go.  In what way is Dylan's
threading model more elegant/integrated than Java's?  Well, okay, Java
does very little that's elegant, but the threading constructs seem
quite capable to me...

> > 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 read through many previous postings about the tradeoffs involved in
introspection.  True, altering the dynamic environment through more
thorough introspection would kill efficiency, but what about simple
inspection without alteration?

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

Actually, I agree that locating classes and methods by name would be
handy.  But I found an old post says that Dylan's naming model makes
that inherently difficult, maybe impossible.

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

At the very least, I'd like to be able to obtain a list of running
threads.

The documentation on the thread library doesn't make a lot of sense to
me.  I need more explanations.  What's all this talk about "owned"
locks, for example?  How does a thread take ownership of a lock?  Why
do notifications need to be associated with locks?  What do I do with
all the global variables I need to make?  ...et al...

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

You might be right...I worried about that, but came to no conclusion.

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

--
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: References: