Date: Wed, 02 Dec 98 14:23:43 -0600 From: "Richard Seaman, Jr." <lists@tar.com> To: "eischen@vigrid.com" <eischen@vigrid.com> Cc: "freebsd-hackers@FreeBSD.ORG" <freebsd-hackers@FreeBSD.ORG> Subject: Re: pthread_cancel() function... Message-ID: <199812022023.OAA00562@ns.tar.com>
next in thread | raw e-mail | index | archive | help
On Wed, 2 Dec 1998 14:13:42 -0500 (EST), Daniel Eischen wrote: >> 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? Sure. That was what I thought I was proposing, except that instead of SYSCALL_xxx it would be _xxx (eg. _read) since that is how libc (not libc_r) is already setup. In the case of libc_r, you probably don't want to alias it to _thread_sys_xxx, since you probably want the wrappers for the blocking syscalls to be used in libc_r. If you rename the uthread syscall wrappers from xxx to _xxx (eg. _read) and then implement xxx as a wrapper of _xxx that implements cancellation points, you'd be consistent. As far as I can tell, to implement cancellation points, you have to wade through the libc code and make the change as you suggest, for each call. Its not really "hard", just a tedious pain in the you know what. That was really my only point. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812022023.OAA00562>