<!-- MHonArc v2.4.4 --> <!--X-Subject: [MUD-Dev] Re: PDMud thread summary --> <!--X-From-R13: Quevf Uenl <ptNnzv-pt.UenlEntr.Sqzbagba.OP.QO> --> <!--X-Date: Sun, 25 Oct 1998 13:51:42 -0800 --> <!--X-Message-Id: 199810252149.OAA02941@ami-cg.GraySage.Edmonton.AB.CA --> <!--X-Content-Type: text/plain --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, [MUD-Dev] Re: PDMud thread summary</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA"> </head> <body background="/backgrounds/paperback.gif" bgcolor="#ffffff" text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000"> <font size="+4" color="#804040"> <strong><em>MUD-Dev<br>mailing list archive</em></strong> </font> <br> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] <br clear=all><hr> <!--X-Body-Begin--> <!--X-User-Header--> <!--X-User-Header-End--> <!--X-TopPNI--> Date: [ <a href="msg00498.html">Previous</a> | <a href="msg00500.html">Next</a> ] Thread: [ <a href="msg00502.html">Previous</a> | <a href="msg00501.html">Next</a> ] Index: [ <A HREF="author.html#00499">Author</A> | <A HREF="#00499">Date</A> | <A HREF="thread.html#00499">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>[MUD-Dev] Re: PDMud thread summary</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Subject</em>: [MUD-Dev] Re: PDMud thread summary</LI> <LI><em>From</em>: Chris Gray <<A HREF="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</A>></LI> <LI><em>Date</em>: Sun, 25 Oct 1998 14:49:23 -0700</LI> <LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> [Niklas Elmqvist:] General comment: thank-you - something I can sink my teeth into, and get an idea of what you are talking about. >class Pipe { >public: > virtual Msg *Recv(ModuleID hCurr); >} >class CallPipe : public Pipe { >public: > virtual void Recv(..) >} Oops - change in declaration there. I'll assume the second Recv should have the same prototype as the first. >Okay. What I have in mind is this: Say we have a running system with one >module loaded, call it A. A belongs to the ParserModule class which has >been subclassed outside of the executable (external inheritance) and >dynamically loaded into the running MUD. OK. I *think* I've seen descriptions of "external inheritance", so I'll ignore it for now. However, if I am understanding correctly, doesn't using this technique preclude using any implementation language other than C++, (and that everyone use the same C++ compiler) since external inheritance requires consistent object layout and virtual function table format? How would modules written in the MUD-language match this layout? The MUD-language and virtual machine could force all entities manipulated by the MUD-language to inherit from whatever base class is the one chose for the external inheritance level. Isn't that kind of restrictive? The net result of this, is "just another C++ MUD" isn't it? If that base class is changed in any way, *everything* has to be rebuilt, possibly including all MUD-language code. Wouldn't that completely invalidate any existing database? What are the benefits that balance these downsides? I'd like to see databases portable from system to system. E.g. one created on say, a SPARC UNIX box is directly usable on an X86 WIN32 box. Since MUD-language code is likely stored in that database, it should be similarly portable. >Module B is loaded in some way (signal or command). B belongs to the >SocialModule class, also externally inherited from the core. What happens >is this: > >1. The module manager takes charge of the situation. The shared lib is > opened using dlopen() (depending on OS, of course). >2. The executable extracts a pointer to the factory function in the lib > (yes, it has to be there) using dlsym(). >3. The executable calls the function, passing it a pointer to the Core > class. This is the basic set of primitives the module may access. Is that a pointer to a Core object, rather than class? I thought C++ classes had no externally visible representation. > The pointer is passed to the constructor of module B (see class > Module) and the function then returns with the new pointer to > the module B object. >4. The module manager adds the new module object to a list. >5. The executable calls B->Init() (that is SocialModule::Init()) and > passes it its new ModuleID. >6. The Init function, which is written specifically for the SocialModule > (it is virtual and overrides the original Module::Init()), does > some initialization and then decides it needs to talk to a parser. > It calls Core::Broadcast() along with a generic status message ("I > am a CommandHandler") >7. Object A (the parser module) receives this message on the broadcast > channel/pipe and decides that it is interested in CommandHandlers. > It calls Core::GetPipe() with the ModuleID it received from the > Message. >8. The intermodule communication manager (CommManager) receives the > request and queries the module manager about the location of the > two ModuleIDs. If on the same system, it creates a CallPipe > (function pointers). If multi-threading is required, it creates a > QueuePipe, and so on. It returns the pipe to the calling module > (A). >9. Module A receives the pipe and immediately calls B on it, telling it > that it is a parser and wants a command grammar and a way to > package data for passing it. >10. Module B provides A with this and then sits idle until information > from A comes through the pipe. This all sounds pretty good to me, but I'm a bit unsure of some of your basic assumptions. Are you assuming in '10.' that each module has its own thread? Are you assuming there can be only one parser module loaded at any given time? If so, what happens when more than one does step 7.? It also sounds like some of the things that have been discussed before are assumed. E.g. in order for your 'CallPipe' to work, the prototype used for a given kind of communication must be pre-determined. I'm still pretty unsure of the flow of control with such a setup. If all modules have a thread, then it is clear that they just sit awaiting something on one of their data-copying inputs. If not, I'm much less sure of this. As I mentioned before, I think there is a good chance that some modules (e.g. socket input) would want to have multiple threads, and that the processing of those inputs, all the way through the system, is what we would like to happen potentially in parallel on a big SMP. >I haven't ironed out any details, as you can tell, and most of this I made >up as I went along. It may therefore be totally demented; I make no >guarantees. But hopefully, it will help in seeing what I envision. Yes, it helps, thanks! -- Chris Gray cg#ami-cg,GraySage.Edmonton.AB.CA </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <ul compact><li><strong>Follow-Ups</strong>: <ul> <li><strong><A NAME="00501" HREF="msg00501.html">[MUD-Dev] Re: PDMud thread summary</A></strong> <ul compact><li><em>From:</em> Niklas Elmqvist <d97elm#dtek,chalmers.se></li></ul> </UL></LI></UL> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00498.html">[MUD-Dev] Re: PDMud thread summary</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00500.html">[MUD-Dev] Re: DevMUD - thoughts.1</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00502.html">[MUD-Dev] Re: PDMud thread summary</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00501.html">[MUD-Dev] Re: PDMud thread summary</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00499"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00499"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> <ul><li>Thread context: <BLOCKQUOTE><UL> <LI><STRONG>[MUD-Dev] Re: PDMud thread summary</STRONG>, <EM>(continued)</EM> <ul compact> <LI><strong><A NAME="00492" HREF="msg00492.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Sun 25 Oct 1998, 17:28 GMT <UL> <LI><strong><A NAME="00495" HREF="msg00495.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, Niklas Elmqvist <a href="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</a>, Sun 25 Oct 1998, 19:45 GMT <UL> <LI><strong><A NAME="00498" HREF="msg00498.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, James Wilson <a href="mailto:jwilson#rochester,rr.com">jwilson#rochester,rr.com</a>, Sun 25 Oct 1998, 21:10 GMT <UL> <LI><strong><A NAME="00502" HREF="msg00502.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, Niklas Elmqvist <a href="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</a>, Mon 26 Oct 1998, 00:09 GMT </LI> </UL> </LI> </UL> </LI> </UL> </LI> <LI><strong><A NAME="00499" HREF="msg00499.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Sun 25 Oct 1998, 21:51 GMT <UL> <LI><strong><A NAME="00501" HREF="msg00501.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, Niklas Elmqvist <a href="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</a>, Sun 25 Oct 1998, 23:08 GMT <UL> <LI><strong><A NAME="00506" HREF="msg00506.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Mon 26 Oct 1998, 02:54 GMT <UL> <LI><strong><A NAME="00513" HREF="msg00513.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, Alex Oren <a href="mailto:alexo#bigfoot,com">alexo#bigfoot,com</a>, Mon 26 Oct 1998, 10:05 GMT <UL> <LI><strong><A NAME="00535" HREF="msg00535.html">[MUD-Dev] Re: PDMud thread summary</A></strong>, Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Tue 27 Oct 1998, 03:44 GMT </LI> </UL> </LI> </UL> </LI> </UL> </LI> </UL> </LI> </ul> </LI> </UL></BLOCKQUOTE> </ul> <hr> <center> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] </center> <hr> </body> </html>