From owner-freebsd-threads@FreeBSD.ORG Wed Apr 9 04:55:22 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F68237B401; Wed, 9 Apr 2003 04:55:22 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81F8943FBD; Wed, 9 Apr 2003 04:55:21 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0033.cvx22-bradley.dialup.earthlink.net ([209.179.198.33] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 193EAK-0007aw-00; Wed, 09 Apr 2003 04:54:57 -0700 Message-ID: <3E940993.FBAFFD70@mindspring.com> Date: Wed, 09 Apr 2003 04:52:51 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Semenyaka References: <20030408164614.GA7236@comp.chem.msu.su> <20030408194944.GA43822@nagual.pp.ru> <20030409112047.GB33265@snark.ratmir.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a44782f05b6ec796e5766c71405451c76b3ca473d225a0f487350badd9bab72f9c350badd9bab72f9c cc: "Andrey A. Chernov" cc: Yar Tikhiy cc: threads@freebsd.org Subject: Re: termios & non-blocking I/O X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2003 11:55:22 -0000 [ ... moved to -threads mailing list, instead of -arch ... ] Alex Semenyaka wrote: > On Tue, Apr 08, 2003 at 11:49:44PM +0400, Andrey A. Chernov wrote: > > IEEE Std 1003.1-200x does not specify whether the setting of O_NONBLOCK > > takes precedence over MIN or TIME settings. Therefore, if O_NONBLOCK is > > set, read( ) may return immediately, regardless of the setting of MIN or > > TIME. Also, if no data is available, read( ) may either return 0, or > > return -1 with errno set to [EAGAIN]. > > Right you are, but the question is a little bit different, namely - what is > _better_ to do: to return 0 or to return -1/EAGAIN. -1/EAGAIN. As was pointed out in Andrey Chernov's posting, the place to fix this is libc_r, not the kernel, since the kernel is doing something permissable, and the side effect you are seeing is a result of your use of libc_r. > Now the first choice > is implemented. And the point IS that in multi-thread environment with > utheads such implementation leads to BAD results. Probably the correct thing to do is to use a blocking thread, instead of one that uses VMIN/VTIME to poll the keyboard in the first place. In other words, an input processing thread. Normally, this will only be a problem if someone tries to add a thread to do some additional processing in some legacy code, without properly maintaining the legacy code. The main problem you will face, if you try to do this in the kernel instead of libc_r, is that each time you call the read, if it behaved the second way, you would stall all threads in the process for VTIME, and you're going to have a hard time getting people to sign off on blocking all threads because one thread makes some call and the kernel captures it for a long latency. This is remarkably similar to the recent discussion about the blocking of all threads in a libc_r program when taking a page fault. -- Terry