From owner-freebsd-current Mon May 12 18:55:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA20081 for current-outgoing; Mon, 12 May 1997 18:55:25 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA20076; Mon, 12 May 1997 18:55:23 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id BAA16864; Tue, 13 May 1997 01:55:01 GMT Date: Tue, 13 May 1997 10:55:01 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: Andrew.Gordon@net-tel.co.uk, hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: PATCHES: NFS server locking support In-Reply-To: <199705121908.MAA08042@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 12 May 1997, Terry Lambert wrote: > I expected to handle the blocking locks using one of three methods: > > 1) The semantic override. Because the locks are asserted > using (struct flock).l_rsys != RSYS_LOCAL (0), we could > decide to generate select() events for the fd's on which > there were outstanding locks. > > 2) The async call gate. Ideally, all potentially blocking > system calls should be usable using an async vs. sync trap > mechanism that cretes an aio context record for the call. > This is actually the ideally method of implementing a > Unversity of Washington style user space threading system, > either for POSIX user space threads, or for SunOS 4.x liblwp > Light Weight Processes. An async call may be polled and > timed out using aiowait() and aiocancel(), respectively. John Dyson's working on POSIX AIO and dual concurrent threading. I'm not sure how far he's gotten though. > 3) The poll(2) interface. This interface allows for events > other than the read/write/except events allowed to select; > there were a number of people in the core team who were > talking about integrating the poll(2) code from NetBSD as > the basis for the select(2) call. A "lock event" could deal > with this. Regards, Mike Hancock