[MUD-Dev] Re: lurker emerges

[Chris Gray]

[Vadim Tkachenko:]

[Double buffering:]

 >I could be wrong, but I wish it rest in piece - it was a performance
 >tuning nightmare. Either your I/O theread hogs all the resources looping
 >idle, waiting for the input, or it lags because of the wrong priority
 >set or bad timing.
 >
 >For me, the blocking I/O and a possibility to interrupt it (exceptions)
 >is a blessing.
 >
 >Comments, anyone?

I'm gonna have to completely disagree here. Double buffering is a very
standard technique for increasing performance. It is completely
independent of polling (so there is no "looping idle"). A common
use of it nowadays is in the lower level parts of graphics systems:

    create image in buffer 0
    which <= 0
loop:
    set hardware to display buffer [which]
    which <= 1 - which
    create image in buffer [which]
    wait for CRT scan to reach end of current frame
    goto loop

CRT controllers can generate an interrupt when the frame is complete,
thus waking up the 'wait'. This is how you get rid of graphics 'tearing',
which is caused by having only one buffer which you are changing while it
is being displayed.

A lot of high-performance software uses double-buffering for I/O as well.
UNIX will often have multiple I/O operations on-going at once, and
will respond to the first that completes. Modern SCSI controllers can
have requests to multiple devices outstanding, and will respond to
whichever finishes first.

[Rant on]

In general, the lack of proper asynchonous I/O is one of my strongest
complaints about UNIX. It is trivial to build blocking I/O on top of
non-blocking I/O, but the reverse is not true. (The 'aio' family of
calls are, I believe, just library routines built on top of the
standard calls using the SIGIO/SIGPOLL facility. Perhaps not - I
haven't investigated them closely.)

I'm bumping into this right now with my simple MUD client. I call out
to an external editor for editing stuff, but the client needs to stay
active while that editing is going on. So, to know when the editor process
is done, I need to set up a SIGCHLD handler and catch the process exit.
However, that is a signal, which if I'm not careful can cause error
reports from 'read's on user input and on read/writes to the socket
to the server. Ick. Give me true asynchronous I/O (like on the Amiga)
anyday!

[Rant off]

--
Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA