I'm guessing you are writing a MUD server in perl here (given use MUD::Net..., if that's the wrong then the following may have no bearing on reality. :) The reason I'm guessing is because you haven't told us anything more than it's mult-user and a network oriented, which could cover many things, eg a web-server, a bulletin board, a irc server, a multi-player solitaire program....

No MUD engine I'm aware of forks, the reason is basically that the network interaction is not the difficult/expensive/interesting part of the program, rather the interaction between the entities is eg. Mobs moving/hunting, players chatting, the sky falling :) or another way of putting it, the main loop is timer driven rather than network driven. So, in order to use a forking model you have to either have all that interaction happening in *each* process AND synchronized between the processes or each forked process talking back to a central process which is probably going to be by something like sockets, at which point you've only increased complexity. Theoretically you could have each entity represented by a process and talking to a central process, which may make sense if designed well but that's probably overly complex. Not to mention that when you fork you make a complete copy of all memory which in a MUD could run near 100 Mb easily

Now that I've told you why I don't think it's a good idea to fork, heres the basic idea of how :) figure out what the network module needs to be able to do, in this case something like read, write, select, connect, disconnect, accept... it doesn't matter how they are implemented, all that matters is given the same arguments they give you the same end result. so accept for fork would be something like

$sock = $mother->accept();
create sharedmem/pipe/unixsocket;
if fork {return identifier($sock)}
else {pass_data_between_socket_and_main($sock)}

[download]
and the select version 
$sock = $mother->accept();
push @socks, $sock;
return identifier($sock)

[download]

In short you've overreached my ability to come up with a decent reason/design/implementation of forking for a MUD :). However if you are doing something else, specifically something where you basically open connections that don't need to interact with eachother then a forking solution makes much more sense and none of what I've said here applies.

In reply to Re: Sockets - IO::Select, fork(), and modularity by tedrek
in thread Sockets - IO::Select, fork(), and modularity by Ionizor

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.