Date: Wed, 02 Dec 98 12:52:57 -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: <199812021852.MAA01941@ns.tar.com>
next in thread | raw e-mail | index | archive | help
On Wed, 2 Dec 1998 13:23:54 -0500 (EST), Daniel Eischen wrote: >> It strikes me that the "pain in the you know what" part of this >> is the syscall wrapping -- though its more than syscalls involved. >> There are also some libc library functions that are manditory >> cancellation points too. >> >> If you wrap a syscall to make it a cancellation point, then each >> function in libc that calls the wrapped syscall becomes a cancellation >> point too. > >Do we really care about that? Isn't a single cancellation check >_before_ the system call is made good enough? 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. Or, am I just missing something here? 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?199812021852.MAA01941>