[MUD-Dev] Dynamic Loading of Modules
Greg Munt
greg at uni-corn.demon.co.uk
Fri Mar 20 21:50:24 CET 1998
On Fri, 20 Mar 1998, Niklas Elmqvist wrote:
> On Thu, 19 Mar 1998, J C Lawrence wrote:
>
> > On Tue, 24 Feb 1998 00:12:50 PST8PDT
> > Niklas Elmqvist<d97elm at dtek.chalmers.se> wrote:
> >
> > > ...and all the functionality such as DB
> > > management, socket I/O and AI would be implemented in free-standing
> > > modules separate from the main executable (at least, I envisioned
> > > this in the beginning).
> >
> > Which abstraction is deeper than Cold (or any other that I know of)
> > has attempted.
>
> Of course, this abstraction comes at a price. Since the modules are very
> decoupled and don't know anything about each other's existence, I need a
> decoupled way of allowing them to exchange information. I envision this
> mechanism as a request chain on which the individual modules can put their
> ear to and listen on (alternatively, register their interest in different
> kinds of requests to a request manager or something).
Reading this made me think of Occam, for some reason...
Occam is a language used by transputers to achieve true parallel
processing. They communicate through data channels, using the following
syntax (from memory):
To output data to a channel:
CHANNEL ! DATA
To input data from a channel:
CHANNEL ? DATA
Each transputer runs a seperately compiled program. The programs
communicate by passing data to a channel, which is then picked up by
another transputer, which is waiting for data on that channel.
In Occam, channels are implemented as datatypes, and can be passed around
via function parameters, etc.
It may be worth looking into, I don't know. HTH, anyway.
--
Greg Munt, greg at uni-corn.demon.co.uk; http://www.uni-corn.demon.co.uk/ubiquity/
"Deliver yesterday, code today, think tomorrow."
More information about the mud-dev-archive
mailing list