From owner-freebsd-threads@FreeBSD.ORG Thu Jun 19 23:37:38 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCB9C37B401 for ; Thu, 19 Jun 2003 23:37:38 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35F0443F3F for ; Thu, 19 Jun 2003 23:37:38 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-uinj93o.dialup.mindspring.com ([165.121.164.120] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19TFWh-0002Hj-00; Thu, 19 Jun 2003 23:37:36 -0700 Message-ID: <3EF2AB6D.67145D17@mindspring.com> Date: Thu, 19 Jun 2003 23:36:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a40cbb8dba2b51d8854231f6ba502e3c69350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: threads@FreeBSD.org cc: Marcel Moolenaar Subject: Re: Implementing TLS: step 1 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2003 06:37:39 -0000 Julian Elischer wrote: > It doesn't see the userland threads and knows nothing aboyut them so it > is physically incapable of setting the register to point to them. > > (though it COULD save and restore the value for threads that have > enterred the kernel I guess, (blindly hoping that they make sense)) This adds the assumption that, following an involuntary context switch, when the next quantum is allocated to the KSE, the thread that was running under that KSE is the one which will be activated, regardless of priority relative to other threads. It further assumes that the thread will not be migrated to another KSE (e.g. on another CPU which is assigning quantum to the process, while the KSE in question is the only one in the "runnable" state in the process at the time of the assignment). Neither of these are valid assumptions. The first one breaks already, in the current implementation, if you are not running a hacked user space scheduler. I don't think this is a reasonable direction to go. Your own suggestion that a second indirection is needed to get the actual thread (and TLS context pointer) is correct, IMO. -- Terry