Date: Thu, 27 Mar 2003 00:34:29 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Jeff Roberson <jroberson@chesapeake.net> Cc: arch@freebsd.org Subject: Re: 1:1 threading. Message-ID: <3E82B795.DDB0C6A4@mindspring.com> References: <20030327020402.T64602-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeff Roberson wrote: > On Thu, 27 Mar 2003, David Xu wrote: > > After reading your 1:1 threading code, I think you needn't > > hack current KSE code to build your own 1:1 threading code. > > Our code allow you to do this, actully, it's my earlier > > idea to let 1:1 be implemented in our M:N code base, but never > > had told this to julian or others. > > It was actually done outside of KSE on purpose. It keeps the API simpler > and cleaner. It keeps the implementation cleaner. It keeps it out of the > majority of the KSE code paths aside from thread_suspend and related > code. > > I wanted something small and stable that built on top of KSE provided > primitives but did not actually use the KSE apis. This makes it easier > for KSE to continue growing and changing while the 1:1 code remains > simple. It also removes some of the cost associated with doing KSE. This isn't really a legitimate argument. Specifically, if the primitives are incapable of supporting your model, then the primitives need to be changed. The main problem that needs to be overcome, in most cases, is that historical designs preclude future work. In this case, your code represents "future work" unanticipated by the previous design. Note that I do not necessarily take this position myself; I think that your work could have proceedded with the KSEGRP per KSE approach, as Julian and David have suggested, rather than the single KSEGRP per process approach you chose. > I intend to keep thr_kill as is since it is the most simple and direct way > to acomplish the POSIX semantics. "POSIX semantics" should always be considered a secondary consideration, since the real intent is to allow *all* semantics as a construction of the available semantics. This is incredibly difficult, I know, but it's why smart people win over stupid people, or average people, when it comes to design issues. We need to take the "best of breed" forward, and exclude the rest (a genetic algorithm, but the best we can approximate at this time). > I have considered using the ksegrp for this purpose but I view that as an > advanced feature not required to get threading off the ground. I'm trying > to take reasonable steps that provide functionality all along the way. This is expediency. Expediency really has no place in Open Source design, since it doesn't really consider the consumers at all, it considers (or is supposed to consider) only the problem space we are talking about itself. That really changes at the whim of public opinion. > > Yes, you may think that KSE progress is slow, but I'd like to think > > KSE progress has been far too slow. Yes. This has to do with inefficiencies of mapping volunteerism to what is considered (by some people) as "the right way". There's really no approach to resolving this (right now) other than "let the best implementation win". If I'm only willing to work on what I consider "more ideal" to mapping the problem space, then your volunteers are not willing to be "managed" into specific implementation details. -- Hopefully, in the future, this will change: we all want to live in an ideal world. At that point, it comes down to games theory, in terms of communicating goals, and information theory, in terms of communicating with other people about the desirability of specific goals. It's easy to cast this in terms of "war games", "mutual security games", or "present politics of public opinon". All you need is a meta-perspective on the problems. Personally, I'm happy to see forward progress without conflict; in the present tense, this means that the KSE work gets used, even if the use is not in line with the eventual design goals. If this takes a 1:1 implementation to keep it from being diked out, I don't care: it's a "drunkards walk" toward the final goal, and so people should shut up about it, since, no matter how you look at it, there's a net positive value to the work. As such, I would like the KSEGRP per thread, instead of the KSEGRP per process code to go forward. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E82B795.DDB0C6A4>