From: James Rogers (jamesr@best.com)
Date: Fri Jul 20 2001 - 17:31:19 MDT
On 7/20/01 3:38 PM, "Ben Houston" <ben@exocortex.org> wrote:
>
> How to implement this programmatically? I would suggest a "function lock"
> or an "object lock" mechanisms kind to how one locks memory in a shared
> memory system (although you could get the parse tree without locking it,
> locking is only required for modifying it). During the time it is locked if
> one tries to execute it an exception will be thrown. Soon as you unlock a
> function or object it will be re-compiled. This would require a little
> modification of the VM but not a huge amount. Java with it's introspection
> capabilities already supports querying for an Objects exposed functions or
> variables, this is just an extension to that.
I don't think you've fully thought through the consequences of what you are
suggesting. Making this work well in the general case would be more
difficult than it appears you think it would, particularly inside the
framework of the existing Java VMs.
An easier way to implement this would be to store the sequence of
programmatic bits in a properly isolated transactional database engine. You
then read your program by fetching some sequence of record ids and doing an
eval of the code. With sufficient isolation, you can keep your threads from
stepping on each other and using an existing transactional engine you don't
have to reinvent some of the rather complicated logic required to implement
such things well. A mildly custom fitted solution of this type would have
some intrinsic scalability characteristics that a lot of other solutions
don't. (This is hardly an original idea by any means -- I've done some "for
fun" work on Python to adapt it in similar fashion and I'm sure others have
too.)
This actually sounds kind of Forth-ish, though I don't have much expertise
in that particular language.
-James Rogers
jamesr@best.com
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:37 MDT