Xref: utzoo news.software.nntp:828 gnu.emacs.gnus:847 Path: utzoo!utstat!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: news.software.nntp,gnu.emacs.gnus Subject: Re: Compatibility problem with GNUS and 1.5.10 NNTP Message-ID: Date: 18 Sep 90 16:43:30 GMT References: <1990Sep6.212932.12457@caen.engin.umich.edu> <1990Sep13.192510.27417@caen.engin.umich.edu> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 65 Nntp-Posting-Host: odin In-reply-to: sdk@shadow.twinsun.com's message of 14 Sep 90 17:33:08 GMT On 14 Sep 90 17:33:08 GMT, sdk@shadow.twinsun.com (Scott D Kalter) said: sdk> So far two solutions have been mentioned to the GNUS vs. NNTP 1.5.10 sdk> problem. [ ... both are bad, because setting nntp-maximum-request to 1 prevents batching of requests, and thus leads to many small one line IPC transactions, and unbuffering stdio means that fgets must read from the socket one char at a time ... ] sdk> I have spent some time looking at both ends of this problem. My sdk> current opinion is that NNTP has some problems in trying to use both sdk> select() and buffered I/O through fgets(). [ ... ] Correct -- select(2) can only know that there are bytes waiting at the socket, does not know about bytes waiting in the stdio buffer. sdk> However, I see three options to solve the problem: sdk> 1. Remove the use of select and simply assume that clients will not sdk> sit around idle for two or more hours. Best quick solution! Just do not define 'TIMEOUT' in "common/conf.h" -- this is by far the easiest and most efficient solution. It is also catered for in the configuration options, requires no modifications, and removes only a very limited use facility, analogous to the c-shell 'autologin'. sdk> 2. Put in an explicit test (before the select call) to see if there is sdk> something still in the buffer and don't make the select call if there sdk> is. [ ... ] As you say, this is very unpalatable. It requires perforating abstraction layers, or rewriting parts of stdio functionality, and also it is very unportable. sdk> 3. Give up on using select and use an alarm instead. sdk> I believe the 3rd option makes the most sense given that we basically sdk> are trying to implement something like a watchdog timer. Yes, I was going to implement it like that, but there is a comment that SIGPIPE is explicitly ignored because in any case we get to know about a severed connection when trying to read. I have also noticed that EINTR is ignored when reading from the socket. This leads me to think: we may want to hang up either because the connection has been dropped, or because the client has been inactive, while keeping the connection alive. I think it is not appropriate to implement the later option ('TIMEOUT'); if the client has been inactive, without dropping the connection, that means that its machine is still up and it is still "logged in". If the client has to be auto-logged out, let's leave the task to the client's machine. sdk> Apparently the NNTP author is working on a fix but any of the above sdk> could be implemented without too much difficulty and without costing sdk> all newsreaders with a setbuf(stdin, NULL);. Well, I have just disabled TIMEOUT. I think that is the best all around solution. Granted, if you want to implement auto-logout on a live but inactive socket in the server, alarm(3) is probably the best way. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk