Date: Wed, 3 Nov 1999 08:23:35 -0700 From: Nate Williams <nate@mt.sri.com> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: Nate Williams <nate@mt.sri.com>, Julian Elischer <julian@whistle.com>, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <199911031523.IAA08555@mt.sri.com> In-Reply-To: <381F85F2.BF6D5A2@vigrid.com> References: <Pine.BSF.4.10.9911020810090.2283-100000@current1.whistle.com> <19991102173736.9E34E1FCD@io.yi.org> <199911022319.QAA26200@mt.sri.com> <381F78AF.D5073BFB@vigrid.com> <199911030016.RAA26726@mt.sri.com> <381F85F2.BF6D5A2@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > The idea of being 'too flexible' scares me. Writing correct threaded > > code is hard, when you start throwing in the complexity of determining > > thread scheduler models, types of threads to create, etc..., and all of > > a sudden multi-process solutions start to look pretty good. > > Well, stick with what you know then ;-) And also make sure whatever > we do gets sufficiently documented! You're missing my point. Writing correct threaded code is hard, and if we make it too difficult, it will have *very* little effect on the userbase, since very few people will be able to write code for FreeBSD. Highly motivated individuals will be able to write code, but if we come up with a very complicated design that requires lots of extra work, very few people will be able to use the new threaded features of FreeBSD. My plea is to keep is simple. KISS rules here, and although flexibility is a grand goal, KISS should always win out. Nate 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?199911031523.IAA08555>