From owner-freebsd-arch Fri Sep 28 9:23:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id E796C37B405 for ; Fri, 28 Sep 2001 09:23:39 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA71230; Fri, 28 Sep 2001 10:02:41 -0700 (PDT) Date: Fri, 28 Sep 2001 10:02:39 -0700 (PDT) From: Julian Elischer To: Alfred Perlstein Cc: Daniel Eischen , arch@FreeBSD.ORG Subject: Re: KSE next steps... In-Reply-To: <20010928065553.D59854@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG it doesn't wink out of existance.. it just returns with an error condition, to the user boundary.. it has to free anything it allocated on the way in.... On Fri, 28 Sep 2001, Alfred Perlstein wrote: > * Daniel Eischen [010928 06:54] wrote: > > On Fri, 28 Sep 2001, Alfred Perlstein wrote: > > > * Julian Elischer [010928 02:44] wrote: > > > > > > > > int abort_thread(struct kt_context *ktc); /* if we find a thread in */ > > > > /* this process that has this ktc, */ > > > > /* then if it is sleeping, abort the syscall */ > > > > /* if it is running, let it continue but set */ > > > > /* flag so that if it tries to sleep, it aborts */ > > > > /* instead */ > > > > > > Unless I'm misunderstanding you, this will not be possible without > > > a tremendous amount of work, a variation that may work is allowing > > > the syscall to run to completion, returning the error code and then > > > aborting it. Too much code would have to change if tsleep became > > > a cancellation point. > > > > Think of this as kill() on a process; it shouldn't be too different. > > If PCATCH is specified in the tsleep, then it is terminated immediately, > > otherwise it just remains pending until (and if) it is checked at a > > later point in time. Regardless of whether PCATCH is specified, the > > thread never returns to userland. The UTS is notified through an > > upcall in the same way that it would be if a thread blocked (but with > > a different completion status). > > This is quite different from winking out of existance when it tries > to sleep. :) > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message