Date: Wed, 17 Jan 2001 10:55:09 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Jason Evans <jasone@canonware.com> Cc: arch@FreeBSD.org, Randell Jesup <rjesup@wgate.com>, Alfred Perlstein <bright@wintelcom.net> Subject: Re: HEADS-UP: await/asleep removal imminent Message-ID: <XFMail.010117105509.jhb@FreeBSD.org> In-Reply-To: <20010117100954.S61852@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010117105509.jhb>