[MUD-Dev] Re: DevMUD: Inheritable modules

[Chris Gray]

[Jon A. Lambert:]

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

I'm not too fond of having a thread for every module. Personally, I
think we might need to classify modules according to how they participate
in things. For example, a module that is a source of input lines can
run the processing of the input line in a thread (perhaps using some
scheme to control the total number of active threads to a reasonable
value). If it then calls an entry in a parsing interface to handle that
input line, that handling can continue in the same thread throughout.
Similarly, if the parsing requires database access, that very same
thread can go through into a DB module. If the DB module needs to do disk
I/O to retrieve the needed value, then it is that thread that sleeps,
waiting for it. (A DB module is one that could readily have its own
thread, to do background flushing, compressing, whatever.)

So, I would like to see all modules be thread safe, but not necessarily
setup to have a thread of their own. I guess that could be done with the
scheme you are suggesting, by just having the main thread for some
modules just exit right away - that module is then only active when
its interfaces are called upon. That seems a bit backwards to me, however -
I think if a module needs threads, it should create them in its module
initialization function (or whenever else is appropriate for it). We
could provide some support in the "core" for thread creation, etc.,
but the native routines seem to be all pretty straightforward anyway.

Thread-switches are not as expensive as process switches, but they are
likely at least 10 times more expensive than a function call.

--
Don't design inefficiency in - it'll happen in the implementation. - me

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA