From owner-freebsd-hackers Wed Dec 2 11:14:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA23638 for freebsd-hackers-outgoing; Wed, 2 Dec 1998 11:14:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA23633 for ; Wed, 2 Dec 1998 11:14:08 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id OAA18143; Wed, 2 Dec 1998 14:13:42 -0500 (EST) Date: Wed, 2 Dec 1998 14:13:42 -0500 (EST) From: Daniel Eischen Message-Id: <199812021913.OAA18143@pcnet1.pcnet.com> To: eischen@vigrid.com, lists@tar.com Subject: Re: pthread_cancel() function... Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm not sure I follow. If I understand, the specs say that the > "read" function should be a cancellation point (as an example). > If you make the read function a cancellation point (even if you > just test for cancellation once, perhaps by calling > pthread_testcancel) how do you prevent the other libc or libc_r > functions that call read from becoming cancellation points > too? > > The problem, as I see it, is that within libc and libc_r, a > function that calls read will get the wrapped syscall, not > the syscall itself, as it is currently implemented. Take > "localtime" as an example. The implementation of localtime > indirectly calls read. This will make localtime a cancellation > point too, even though localtime is not a cancellation point > defined in the specs. Change libc to use SYSCALL_xxx (in this case SYSCALL_READ), where SYSCALL_xxx is defined in libc as xxx and in libc_r as thread_sys_xxx? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message