Xref: utzoo news.software.nntp:824 gnu.emacs.gnus:842 Path: utzoo!utstat!news-server.csri.toronto.edu!cs.utexas.edu!usc!orion.oac.uci.edu!ucivax!ucla-cs!twinsun!twinsun!sdk From: sdk@shadow.twinsun.com (Scott D Kalter) Newsgroups: news.software.nntp,gnu.emacs.gnus Subject: Re: Compatibility problem with GNUS and 1.5.10 NNTP Message-ID: Date: 14 Sep 90 17:33:08 GMT References: <1990Sep6.212932.12457@caen.engin.umich.edu> <1990Sep13.192510.27417@caen.engin.umich.edu> Sender: news@twinsun.com Organization: Twin Sun, Inc. Lines: 56 In-Reply-To: stealth@caen.engin.umich.edu's message of 13 Sep 90 19:25:10 GMT Nntp-Posting-Host: shadow So far two solutions have been mentioned to the GNUS vs. NNTP 1.5.10 problem. 1. (setq nntp-maximum-request 1) which makes emacs and the NNTP server work in a synchronous lock-step -- emacs makes one request, NNTP answers, emacs makes one request etc. It seems intuitive to allow emacs to make several requests without making it wait for NNTP to respond. 2. setbuf(stdin,NULL) which solves the problem by forcing NNTP to not ignore buffered requests (by eliminating the buffer). This isn't so hot a solution since it forces NNTP to do a read() for each and every input character! I have spent some time looking at both ends of this problem. My current opinion is that NNTP has some problems in trying to use both select() and buffered I/O through fgets(). After staring at this code for an hour I realized that there are a couple of things to note: 1. The select is used as nothing more than a timeout mechanism to decide when the server has been idle too long and should be shut down. 2. There is an evil bug lurking in this code in that if a client should send a string with no carriage return and then stops sending anything it will hang the NNTP server and that select() isn't going to help one bit (it will hang in the fgets()). Granted (2) is much more unlikely than having a well behaved client that only makes complete requests and then sits idle for two hours (the standard timeout for select here) indicating the server should just give up. However, I see three options to solve the problem: 1. Remove the use of select and simply assume that clients will not sit around idle for two or more hours. 2. Put in an explicit test (before the select call) to see if there is something still in the buffer and don't make the select call if there is. This could be done (non-portably) by poking in _iobuf->_cnt described in stdio.h or by building one's own buffering scheme (portably). 3. Give up on using select and use an alarm instead. I believe the 3rd option makes the most sense given that we basically are trying to implement something like a watchdog timer. If the timer goes off, just shut down this server process (which is what select does if it times out). Apparently the NNTP author is working on a fix but any of the above could be implemented without too much difficulty and without costing all newsreaders with a setbuf(stdin, NULL);. -sdk