On the subject of improved editting with this new age of OLC and such, I've been working on a different approach to editting and I'm curious if anybody is interested in what I have been working on. It's an external shell of an editor, (I'll explain in a few), and I think it's good for those who like to mess around with network programming and such. Ok, what it is: Basically the mud forks off a 'pseudo server shell' then continues on with whatever it's doing. The shell then sets up some descriptors and opens a pty device (pseudo terminal, god I love the word pseudo), the shell then forks once more and the child is the exec branch, closing all stdXXX descriptors after it dup()s them from the previously opened pty device. The parent of the shell sets up a mini telnetd to route io from the main mud to the exec branch. What does it mean? Well, simply put, someone logged onto the mud can spawn outside of the mud, and in this case, I have them go directly into a secured editor, spico (yes, mud++, much credit to the crew there for giving me something to look at). Upon exit of the editor, the exec branch dies of course, and sends a SIG_CHILD to mommy, which mommy then catches the signal with a new signal catcher function which I aptly named grim_reaper(). In that catcher, the mud uses a wait3() with WNOHANG flag to see which child_pid just died. Then it can scan the list of player descriptors in the mud to match that pid and see who just left the external editor. It finds the one, removes a flag on the descriptor_data, and voila the players io gets rerouted back to the mud. Since I got the basics working, I have incorporated it into my olc and it seems to work great, just like sitting at a terminal and typing pico. Though the mini-telnetd (which I just scarfed from the one in mud++) doesn't work well with anything but a natural telnet client that doesn't try to interpret a lot of special characters, like tintin or zmud. With a natural telnet connection, it works great. If anyone is interested in this lemme know, I've been doin a bunch of work on it and am about to try some vfork() calls in place of the standard fork() because forking a 15 meg mud 20 or 30 times results in incredibly poor performance as you can imagine. Im looking for perhaps someone who knows netty prog a bit to maybe go thru it and catch any bugs or performance busters I may have included (other than the previously mentioned fork() calls) Perhaps after a few more performance tuners, I'll just throw it on the code snippet site. Btw, RoA runs on a FreeBSD machine and I haven't even begun to try to make it portable, it should be ok on any BSD type OSs. (heh, next step... modular compilation on the fly) jtrhone aka vall RoA +-----------------------------------------------------------+ | Ensure that you have read the CircleMUD Mailing List FAQ: | | http://cspo.queensu.ca/~fletcher/Circle/list_faq.html | +-----------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/18/00 PST