🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.emacs.bug
Article #98411

select

#98411
From: Mike McNamara
Date: Tue, 06 Aug 1991 15:21
99 lines
4288 bytes
	I have a question for the illuminati:

Shouldn't emacs do something when select returns an Exception ?

Currently, the select behaviour, in process.c, in 
	wait_reading_process_input is as follows:

#ifdef IBMRTAIX
        nfds = select (MAXDESC, &Available, 0, 0, &timeout);
#else
#ifdef HPUX
        nfds = select (MAXDESC, &Available, 0, 0, &timeout);
#else
        nfds = select (MAXDESC, &Available, 0, &Exception, &timeout);
#endif
#endif

	So, IBM and HP explicitly ignore Exception events.  All other
systems that use select, select for Exception events.

	Later in the code, there is a loop that reads any data that
select has told us is available:

	   /* Check for data from a process or a command channel */

      for (channel = 3; Available && (channel < MAXDESC); channel++)
        {

	This loop neither checks nor clears Exception events.

	Hence, if a system returned an Exception on a file descriptor,
but not Available, emacs would consume lots of cpu time in
wait_reading_process_input, as the select would succeed, but the read
loop would ignore that file descriptor.  Perhaps the folks doing the
IBM and HP ports noticed this and just didn't select for Exceptions.

	But what if an Exception event happend?  Further, what if that
Exception event generated some data on a file descriptor? Since the
process is not selecting for Exception, it will not do a read until
Available got set for that file descriptor.  At that time, it would
read the Exception data, followed by the Available data.

	The titan is a system V machine with many berkely extentions,
including select. It emulates select in libc.a with the poll system
call. 

	I have altered the read loop in wait_reading_input as follows:



      /* Check for data from a process or a command channel */

      for (channel = 3; (Available || Exception) && (channel < MAXDESC); channel
++)
        {
#ifdef titan
        /* When an exceptional event occurs, (i.e., an out of band
           message is delivered) discard any data associated with it.

           Without this (ahem, "hack"), every subprocess initiation on the
           titan was prefixed with a ^P (0x10) which was merely annoying when
           starting a shell subprocess, but would break server.el:
           "^PClient 401: /etc/passwd"...

           Question to the gnu-world: what does everyone else do with
           Exception events? I notice that above in the select call,
           HP & IBM explicitly do not select for exceptions; others select for
           them, but pay no attention to the value in &Exception.

           You should note that select'ing for both readable (Available) and
           exceptions (Exception), but only doing channel reads based on bits
           set in Available can eat gobs of cpu time if an exception event
           happens on one of your channels....

        */
          if (FD_ISSET (channel, &Exception))
            {
              int ndiscarded;
              char chars[512];
              FD_CLR (channel, &Exception);
              proc = chan_process[channel];
              ndiscarded = read (channel, chars, sizeof chars);
            }
#endif /* titan */

	...


	Comments, any one?

	-mac

	PS: what do you think about copyrighted software?
--
+-----------+-----------------------------------------------------------------+
|mac@kpc.com| Increasing Software complexity lets us sell Mainframes as       |
|           | personal computers. Carry on, X windows/Postscript/emacs/CASE!! |
+-----------+-----------------------------------------------------------------+
Technical Details
Message-ID: <MAC.91Aug6112116@gold.kpc.com>
Path: arc1-ca.pugleaf.net!gmdzi!unido!mcsun!uunet!cis.ohio-state.edu!gold.UUCP!mac

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fb2f1,4e44516eeac3c9c4,start
X-Google-Attributes: gidfb2f1,public
X-Google-ArrivalTime: 1991-08-07 02:37:24 PST
Path: arc1-ca.pugleaf.net!gmdzi!unido!mcsun!uunet!cis.ohio-state.edu!gold.UUCP!mac
From: mac@gold.UUCP (Mike McNamara)
Newsgroups: gnu.emacs.bug
Subject: select
Message-ID: <MAC.91Aug6112116@gold.kpc.com>
Date: 6 Aug 91 15:21:16 GMT
Sender: gnulists@ai.mit.edu
Reply-To: mac@kpc.com (Michael McNamara)
Distribution: gnu
Organization: Kubota Pacific Computer Incoporated, Santa Clara, CA
Lines: 99
Approved: bug-gnu-emacs@prep.ai.mit.edu