Date: Wed, 03 Nov 1999 11:57:21 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Nate Williams <nate@mt.sri.com> Cc: Julian Elischer <julian@whistle.com>, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <38206971.8D69C9E2@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> <199911031523.IAA08555@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote: > > > > 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. I'm trying to facilitate a POSIX compliant interface providing all the features that POSIX and SSv2 pthreads provide. I'm not advocating adding all sorts of non-portable interfaces. We may end up playing games like Solaris does with PTHREAD_SCOPE_PROCESS threads being created and bound to 'kernel schedulable entities', though, but I don't see this being a problem. > 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. I agree, but I don't see SA plus ability to bind threads to KSEs as being all that complicated. I like SA because it makes the threads library much easier to implement than it would be with an approach like LinuxThreads where there would be all sorts of locking problems. Think of all the work that libc_r currently has to do to prevent blocking in the kernel. SA would eliminate that. Dan Eischen eischen@vigrid.com 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?38206971.8D69C9E2>