[Code] [Sorta] Alternate Editors

From: JTRhone (ujtr@lady.cs.sunyit.edu)
Date: 10/29/96

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)


| 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