Re: pthread cancellation points missing for fdatasync and lockf in some cases

[Mike Frysinger <vapier at gentoo dot org>]

On Saturday 05 May 2007, Carlos O'Donell wrote:
> On 5/5/07, Mike Frysinger <vapier@gentoo.org> wrote:
> > POSIX requires fdatasync() and lockf() be pthread cancellation endpoints
> > but it looks like they get missed a little in glibc ...
>
> Is there a reference for this?

http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html#tag_02_09_05_02

> > fdatasync() is generated for Linux simply via syscalls.list as a pass
> > through to the kernel... the generic case in misc/fdatasync.c relies on
> > fsync() being a cancellation endpoint ... so here, just Linux is broken
> > it seems
>
> A patch for this would be to add "C" to the fdatasync signature in
> syscalls.list.
> See make-syscalls.sh.

ah, make-syscalls.sh doesnt document this ... i'll post a patch for that :)

> > as for lockf(), this seems to be [incorrectly] done on purpose ...
> > io/lockf.c talks about relying on fcntl()'s cancellation endpoint when
> > called with F_SETLKW as that is the only case that POSIX says fcntl()
> > should be a cancellation endpoint ... however, POSIX does not grant this
> > limitation to lockf() ... it should always be a cancellation endpoint
> > regardless of the arguments it is called with
>
> Use LIBC_CANCEL_ASYNC/LIBC_CANCEL_RESET to fix this.
> Then write a test to prove it works? :-)
>
> Care to file this in the bugzilla so we don't forget.

i wanted to make sure these things werent done on purpose first ... but i'll 
post a patch

i have a mondo test case that tests all functions listed as required in the 
spec that i wrote for uClibc ... i was testing it against glibc to make sure 
the test was sane so that's how i noticed these two funcs ... but i'm not 
sure if that test case people would be interested in ...
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.