On Mon, 11 Sep 1995, Carter T. Shock wrote:
>
> Yes and no. Select does poll open descriptors, but in the circle code
> it is wholly unnecessary. All of the circle sockets are set to non-blocking.
> A socket listed in the input set after select is called is assured not
> to block on a read(). i.e. redundant.
I know the sockets are set to non-blocking, I _think_ the reason select
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