From owner-freebsd-fs Sun Mar 1 17:59:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA16456 for freebsd-fs-outgoing; Sun, 1 Mar 1998 17:59:38 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA16448 for ; Sun, 1 Mar 1998 17:59:33 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id BAA22584; Mon, 2 Mar 1998 01:58:20 GMT Date: Mon, 2 Mar 1998 10:58:20 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: Bruce Evans , eivind@yes.no, fs@FreeBSD.ORG, jlemon@americantv.com Subject: Re: syncer / SMP question In-Reply-To: <199803011117.EAA29852@usr09.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 1 Mar 1998, Terry Lambert wrote: > > Not an option :-), and leaves mp locked (which you can't know about since > > its locking is hidden in the loop macros). In general, you would need > > macros for all sorts of abnormal loop exits. > > Like NFS. And then you might end up with hard to track bugs. > Like NFS. > > Single-entry/single-exit is good. But don't write Homeric epics in > header files to achieve it. 8-). When we start the pushdown in the the fs systems and do about 6 to 9 months of debugging without getting anywhere, maybe we should consider looking at a new locking model. ;-). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message