From owner-freebsd-threads@FreeBSD.ORG Tue Feb 10 06:53:44 2004 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 6421F16A4CE; Tue, 10 Feb 2004 06:53:44 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 224E143D1F; Tue, 10 Feb 2004 06:53:44 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i1AErgfo017272; Tue, 10 Feb 2004 09:53:43 -0500 (EST) Date: Tue, 10 Feb 2004 09:53:42 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Xu In-Reply-To: <40287A33.9050008@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: tege@swox.se cc: freebsd-threads@freebsd.org Subject: Re: kern/33951: pthread_cancel is ignored 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: Tue, 10 Feb 2004 14:53:44 -0000 On Tue, 10 Feb 2004, David Xu wrote: > Daniel Eischen wrote: > > >Synopsis: pthread_cancel is ignored > > > >State-Changed-From-To: open->closed > >State-Changed-By: deischen > >State-Changed-When: Mon Feb 9 21:30:56 PST 2004 > >State-Changed-Why: > >This works under -current with libpthread and supposedly > >under -stable with -lc_r. > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=33951 > >_______________________________________________ > >freebsd-threads@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-threads > >To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > > > > > > > > > I had enabled asynchornous cancelling for M:N thread in libkse but not > 1:1 thread, > simplest way to support asynchronous cancelling for 1:1 is to use > signal, but it will > occupy a signal like Linux's SIGUSR1, another way is to use upcall, > but it is > slight complicated. An upcall would be nice since it wouldn' use a signal. It could be treated like a signal where you push it on the thread's stack but use the upcall function instead of a signal handling function. -- Dan Eischen