[MUD-Dev] Re: DevMUD: Inheritable modules

[Jon A. Lambert]

On 30 Oct 98, James Wilson wrote:
> On Fri, 30 Oct 1998, Adam J. Thornton wrote:
> 
> >I think there ought to be a one-to-one thread-to-connection mapping (there
> >may of course be non-connection oriented threads going on, but each
> >connection presumably requires its own thread, unless we want to make the
> >I/O model nonblocking, which I think will get unwieldy for large numbers of
> >players).  Also message queues of some sort to handle the data that each
> >connection is transporting. >
> 
> async i/o and thread pools scale much better than thread-per-connection,
> as I understand it.

I mentioned in an earlier post about not having a core but a set of 
modules that together implement core functionality....so in that
vein...

Why couldn't each module implement it's own desired level of 
threading.  The loader would dynamically load the module and then 
start it running using a createthread(), startthread() mechanism.  
Each module then starts as a single thread. The module writer need 
not even be concerned that they are threaded. Since there seems to be 
agreement that a common module interface is necessary, why not make 
that small bit of common inter-module interface code thread-safe by 
issuing the necessary locking mechanisms within the interface wrapper 
itself.  

ModuleA calls ModuleB wrapper ----> ModuleB function
ModuleB calls ModuleA wrapper ----> ModuleA function

All the code in the wrapper is fully reusable, generic and 
threadsafe.  It just contains bindings (data) for the module 
it is attached to.  Creation of wrappers could even be 
automated.  It might also be useful to require the loaded
module to use a standard function name (i.e. init()) so
we can have a handle to start a thread on.  And perhaps
a kill() or stop() handle.

The base loader could:

dynamic_load()
process_symbols()
build_wrapper()
create_thread()
start_thread()

A module wrapper's data portion might contain a simple message 
queue and handled as such.  Thus a module could call 
the wrapper function receive_message() which pops() the wrapper
queue and causes one of the modules routines to be executed.
The return of the function would of course occur in the wrapper
and any return value is sent_back to the caller via a wrapper
function send_message().  Note that the owning threads during
function calls will be the called module's.  So single-threaded
modules can interface easily with multi-threaded modules.

Just some more strange thoughts... :)

--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--