One select() call is used to make the MUD sleep. Another select() call is used to poll the sockets for input and exceptions. The third select() call is used to achieve a fixed loop timing. You have no way of knowing how long a main loop cycle will take, so the amount of time between .25 seconds (4 loops/second) and how long the last loop took is used as the time value for a NULL select(). Nothing is actually checked, but it is used to make the MUD sleep. The sleep() call doesn't take floating point's as arguments, but select does, so that is used. This is why you can't simply eliminate the select() calls from DIKU or Circle code in favor of checking each socket. The reason a signal mask is needed is so that the select() calls are not interrupted by spurious signals. (Signals you're not expecting). Hope this clears up some questions. --- Christopher Herringshaw | University of Michigan Medical Center Special Projects Development | 1500 East Medical Center Dr. B1-240TC xxviper@umich.edu | Ann Arbor, Michigan 48109-0704 http://www.umich.edu/~xxviper | +0101 (313) 747-2778 On Mon, 11 Sep 1995, Trey T. Morita wrote: > is still used is to speed up processing. No need to try to read a socket > if select doesn't show it has input pending. Like I said, there are 3 > calls to select in the main game loop. The 1st is to make the MUD "sleep" > when there are no connections, and could be removed with the only effect > being that your MUD wouldn't sleep. The third is the "poll", but I dunno > yet what the 2nd one is for. The 2nd is preceded by a large comment block > which still doesn't tell me anything. The fact that the 1st sentence is > fucked doesn't help. "At this point, the original Diku code set up a > signal mask to avoid block all signals from being delivered."?? It looks > like he switched from one sentence to the next after 'avoid'. So anyway, > I don't exactly thing you could kill all the select calls, they're needed > for delay I think. > > > Kill the select calls and just attempt > > to read all of the sockets. read() can return in basically two ways: > > 1) it can return the number of bytes read. Even if interrupted by a signal. > > 2) It can return -1 and set the external global "errno" in the event of error. > > All you have to do is check for the -1 on return. For a non-blocking socket > > if errno == EWOULDBLOCK, make read return 0, any other error, close the socket. > How long does read() wait for input? > > > And you _should_ worry about the exception set if you use select. Close any > > sockets in that set... they are corrupt. > Yeah I know, but the code's already in there for it, I meant he shouldn't > mess with it. > > > <explanation of telnet deleted> > Hehe, that's just it, I'm not real clear on telnet, for the most part. > For example, I had no idea you could change modes from line-by-line to > character at a time. > > > > were read using stdio functions, you could probably do it . . . > > > > > How else do you plan to read a socket? :) > Uhh, I wasn't, but that doesn't mean there isn't some other way . . :) > > > If anyone is interested, I've worked up a C++ class to do socket handling > > and I'm working on a class to negotiate telnet options. It would seem that the > > best solution would be to handle both instances of user input - > > line-by-line and char-by-char. If the user is in line-by-line mode > > don't bother with all of the command line completion/editing stuff > > (though it is reasonable to try to complete any abbreviations sent). > > If they're in char-by-char mode, then searching the input stream for > > special characters is trivial. Defaulting to char-by-char mode is always > > the safest tact however... If you start to rely on the terminating newline > > from line-by-line mode everything blows up if that last pair of bytes > > is lost on the net. Have I babbled enough? > Err, what's the default for telnet? line-by-line I'm guessing . . . > line-by-line would be less traffic-intensive, since backspace/corrections > would be handled locally. > > > > > -Todd (slart at The Void rosebud.umiacs.umd.edu 4000) > > > > PS: for the command line completion (and other tricks) you can treat > > the set of circle commands as a grammar and parse it with lex/yacc. > > Any interest in a discussion of this? > > > Uhh, not familiar with lex/yacc . . > > Trey > (Cyntax at StrangeMUD, also at UMD - engrol32.eng.umd.edu 9332 > and AnonyMUD - bermuda.io.com 4000) > >
This archive was generated by hypermail 2b30 : 12/07/00 PST