ð thus on Mon, 18 Dec 1995 01:42:09 -0500 (EST), John virtually scripted... >> > I can't wait, no more lag from gethostbyaddr *bounce*. >> >> Profile those fork() calls though, its one of the slowest system calls! >> If your platform supports vfork() use that, but plain old fork() is a >> major performance hit. >> John> Fork is EVIL. Our head coder has threatened to kill anyone who uses John> it :P. John> My understanding is what we will have, is that upon starting the mud John> server will spawn a seperate process (just one). This 2nd process, John> will be a daemon which will pass characters on to the main process John> after all the login BS. A lot of the discussion I've seen on here is John> sentered around starting a process for every new connection. We'll John> only have 2 processes and never more for the mud. actually i would rather have the spawned process be the server, with the master process being connection handler. instead of the server process sending the kernal an alarm request, it would send the master a signal to act as an alarm, in which case if an infinite loop arose, the master process would usurp its child's descriptors, closing them gracefully, and then crashing. i'll have to brush off my IPC source. d. -- ``you... bred raptors?!'' - alan grant, jurassic park
This archive was generated by hypermail 2b30 : 12/07/00 PST