From owner-freebsd-arch@FreeBSD.ORG Thu Apr 3 01:57:17 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 550F237B401 for ; Thu, 3 Apr 2003 01:57:17 -0800 (PST) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id A67DD43F3F for ; Thu, 3 Apr 2003 01:57:14 -0800 (PST) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h339v6mF099450; Thu, 3 Apr 2003 13:57:06 +0400 (MSD) Date: Thu, 3 Apr 2003 13:57:06 +0400 (MSD) From: Igor Sysoev X-Sender: is@is To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: libthr and 1:1 threading. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 09:57:17 -0000 Terry Lambert wrote: >> Well, they're both fixes. Another issue for applications that are >> threaded and may be bumping up against the system memory limits is whether >> or not the whole process stalls on a page fault or memory mapping fault, >> or whether it's just the thread. >This is what I meant by "deeper in the system calll layer". IMO, >if you are stalled on something like this on an async fd, then it >should queue the fault anyway, and return to user space for the >next request. This may just be a bug in the kernel processing of >demand faults on vnodes associated with async fd's (FWIW, System V >and Solaris both queue the fault for kernel processing, and then >return to user space). If a process caused a page fault or memory mapping fault at user level where do you suppose to return in user space after a fault was just queued ? To the same instruction that caused this fault ? With threads you can run another thread in such situation. BTW what do you mean by 'async fd' in Solaris ? O_ASYNC ? I do not see it in Solaris 8. O_NONBLOCK ? It does not matter for disk files. aioread() or aio_read() ? They are library calls that implemented via additional LWP for regular disk files. >> Certainly, you can argue that the application should be structured >> to make all I/O explicit and asynchronous, but for various reasons, >> that's not the case :-). >The mmap'ed file case is obviously not something that can be >handled without an explicit contract between user and kernel >for notification of the pagein temporary failure (I would use >a signal for that, probably, as a gross first approximation, >but per-process signal handling is currently not happy...). And what do you suppose to do in a signal handler ? Using some non-reenterant library functions ? Igor Sysoev http://sysoev.ru/en/