Re: fork, vfork, shared mem, et al... (fwd)

From: John T. Cox (
Date: 12/20/95

> > I apologize for actually using this mailing list for its intended
> > purpose, but you'll just have to deal with it. ;p
> > 
> > I've been sort of thinking about how to go about rewriting Circle for a 
> > fork/vfork/etc style of input and output.  It would be a MAJOR rewrite, 
> > of course...  or at least a big one.  However, since this would be my 
> > first experience with real official multitasking, it shouldn't hurt me to 
> > think about it a little (in the event that I need to use it at a later 
> > date, or ever get around to doing that rewrite).
> > 
> [snip]
> I've been following this thread a bit and I just have to ask one 
> question.  Why?  What are you trying to accompilish by doing this?  Such 
> an undertaking is going to require extensive coding and testing.  What 
> problem in the stock circle code do you think you are going to overcome 
> by writing this much code?
Well, one good example is gethostbyaddr. With 300+ people when the mud lags
for 10 seconds or so becuase of this, the complaints are horrendous. We
even keep a local host file for name lookups, but there are new sites
everyday and if you have to go out on the net to get it... The problem is
that gethostbyaddr is a blocking function. Meaning that the mud will not
process anything else until that function is done.

Personally, I don't like fork, et al. The approach we're taking is to have
a single daemon running which will handle all new connections then pass them
to the mud when it's done. Now, people can still get lagged there, but we
feel it's much better to have 10 people lagging instead of 350.

There are other reasons, like I'll bump up the timeout for ident after we've
finished testing the daemon.

Mielikki @ SojournMUD ( 9999)

This archive was generated by hypermail 2b30 : 12/07/00 PST