Date: Fri, 28 Sep 2001 10:02:39 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Alfred Perlstein <bright@mu.org> Cc: Daniel Eischen <eischen@vigrid.com>, arch@FreeBSD.ORG Subject: Re: KSE next steps... Message-ID: <Pine.BSF.4.21.0109281001340.71138-100000@InterJet.elischer.org> In-Reply-To: <20010928065553.D59854@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <eischen@vigrid.com> [010928 06:54] wrote: > > On Fri, 28 Sep 2001, Alfred Perlstein wrote: > > > * Julian Elischer <julian@elischer.org> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0109281001340.71138-100000>