From owner-freebsd-threads@FreeBSD.ORG Mon Apr 7 04:37:09 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 A358F37B48F for ; Mon, 7 Apr 2003 04:37:08 -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 21E7B43FDF for ; Mon, 7 Apr 2003 04:37:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0041.cvx22-bradley.dialup.earthlink.net ([209.179.198.41] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 192Uvw-0007iw-00; Mon, 07 Apr 2003 04:37:05 -0700 Message-ID: <3E91628D.6D0D7D3C@mindspring.com> Date: Mon, 07 Apr 2003 04:35:41 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Sysoev References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4d64f59b3a9565961bf7ba04523a81f63548b785378294e88350badd9bab72f9c350badd9bab72f9c cc: freebsd-threads@freebsd.org Subject: Re: libc_r and non-blocking disk 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: Mon, 07 Apr 2003 11:37:09 -0000 [ Moved to freebsd-threads, where it should have been posted in the first place ] Igor Sysoev wrote: > I mean that if FreeBSD would support select() for disk files there can > be the programs that will use this feature directly without any wrappers > and these programs would have the portability problems. Select will simply return "true" for disk files on all systems that don't support the idea of "disk I/O in progress/disk I/O complete". Such systems would eat the 20ms stall that FreeBSD is eating today in lib_r's non-blocking I/O case. Therefore code written to expect this behaviour will work portably on all systems; as you note, worst case, there's an extra (useless) call to select(), which harms nothing. > It's something like some Linux programs use a specific signal > behaviour of Linux clone()d pthreads. We could enumerate portability issues until we has 5 foot beards; a benign select() is much less of an issue than, for example, the fact that Linux programmers often fail to bzero() sockaddr_in's they declare on the stack, because Linux works without you doing that, and FreeBSD, SVR4, Solaris, etc., do not. I don't think it's useful to call a benign select() a "portability problem"; certainly, it's not in the same class as malignant portability issues with signals or sockaddr_in's, etc.. -- Terry