From owner-freebsd-arch Wed Jan 17 10:55:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id CF2EB37B6C8 for ; Wed, 17 Jan 2001 10:55:37 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0HIrGL38304; Wed, 17 Jan 2001 10:53:16 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010117100954.S61852@canonware.com> Date: Wed, 17 Jan 2001 10:55:09 -0800 (PST) From: John Baldwin To: Jason Evans Subject: Re: HEADS-UP: await/asleep removal imminent Cc: arch@FreeBSD.org, Randell Jesup , Alfred Perlstein Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Jan-01 Jason Evans wrote: > [-current trimmed] > > On Wed, Jan 17, 2001 at 09:21:09AM -0800, Alfred Perlstein wrote: >> 3) no one uses it! :) >> >> 4) most anything you need asleep for could probably be done with >> mutex/cv's. >> >> I'm not going to axe it for a few days, this is a really amazing >> API that Matt added, the problem is utility and useage over code >> complexity. > > I support its removal. I would argue that not only _could_ most uses of > asleep instead use mutexes and condition variables, but they _should_. The > fact that asleep()/await() aren't used to any significant degree, along > with the fact that there are other ways to accomplish the same thing, means > that we have an easy opportunity to reduce the complexity of our kernel by > removing unused code. > > At the time that Matt wrote the code, it made sense, and if we hadn't gone > the direction of using BSD/OS's SMP architecture, it probably would have > been used quite a bit. Well, it will be unused if we axe all tsleep's in favor of cv's which does incur extra overhead, as each cv has to be init'd and destroy'd and carries a linked list around with it. The extra storage overhead doesn't outweight the speed increase (from lack of the hash lookup) in all cases I think, so I'm not sure we want to axe tsleep() just yet. If you axe tsleep() then asleep() can be emulated by either passing cv's around between functions. > Jason -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message