POSIX bashing (readline bashing)

John F Haugh II jfh at rpp386.cactus.org
Tue Apr 2 15:59:48 AEST 1991


In article <70433 at brunix.UUCP> cgy at cs.brown.edu (Curtis Yarvin) writes:
>Certainly.  On a 100-user mainframe, canonical mode is not a marginal
>optimisation.  My point was that the good 'ol 9600 bps terminals & large
>time-sharing systems are likely to pass away soon, except in heavy-duty
>transaction processing environments.  Networking technology (in my opinion)
>has become simple, reliable, and effective enough that a mainframe is rarely
>the most cost-effective option when purchasing a new system.

There are no "100-user mainframes".  The S/6000, which is a microcomputer
by all accounts, supports well over 100 users.  The 3090/600E I use for
problem tracking supports about 4,000 users total, with the particular
virtual machine I access most running close to 1,000 simultaneous sessions.
Other virtual machines on that CPU run well over 2,000 simultaneous
sessions.

>Typing away on what?  sh? ed?  If they're using a shell with editable
>history (as most prefer), or they're editing a file, they're in raw mode.
>If you have such a mongo mainframe around, and you have kmem privileges, it
>might be interesting to run some tests and see exactly how much time is
>spent in canonical mode.

Block mode terminals and "cooked" mode tty I/O were developed specifically
to get around the issues of interrupt service.  Deferring as much of the
processing to as late a time as possible lets you do it all at once, without
running in circles performing needless context switches.  Using the GNU
readline() code will aggrevate matters further because it is a PIG.

You don't need to snoop about too hard - just turn profiling on for your
kernel (for System V types).
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) |  Domain: jfh at rpp386.cactus.org
"I want to be Robin to Bush's Batman."
                -- Vice President Dan Quayle



More information about the Comp.unix.internals mailing list