Re: new syscall stub support for ia64 libc

[David Mosberger <davidm at napali dot hpl dot hp dot com>]

>>>>> On Mon, 17 Nov 2003 10:07:34 -0800, Ulrich Drepper <drepper@redhat.com> said:

  >> Related question: it seems to me tst-cancel6 cannot possibly
  >> succeed with NPTL _unless_ HAVE_FORCED_UNWIND is true?

  Uli> That might be.  It's no supported configuration anyway.  I
  Uli> think it's time to make configure fail in all these
  Uli> non-standard environments.  It was mainly useful when
  Uli> developing.  But now all the tools are there.

Looking some more into the cleanup-handler-based locking, I'm not sure
I understand why it is race-free.  If I'm reading the code right,
we've got:

nptl/sysdeps/pthread/bits/stdio-lock.h:

	#  define _IO_acquire_lock(_fp)				\
	  do {							\
	    _IO_FILE *_IO_acquire_lock_file			\
	        __attribute__((cleanup (_IO_acquire_lock_fct)))	\
	        = (_fp);					\
	    _IO_flockfile (_IO_acquire_lock_file);

libio/libioP.h:

	static inline void
	__attribute__ ((__always_inline__))
	_IO_acquire_lock_fct (_IO_FILE **p)
	{
	  _IO_FILE *fp = *p;
	  if ((fp->_flags & _IO_USER_LOCK) == 0)
	    _IO_funlockfile (fp);
	}

What happens if a thread gets canceled right after declaring
_IO_acquire_lock_file, but before the _IO_flockfile() call?  Wouldn't
that cause the cleanup-handler to be invoked and then
_IO_funlockfile() to be called erroneously?

Or is NPTL simply not making any correctness-guarantees when
PTHREAD_CANCEL_ASYNCHRONOUS is in effect?  If so, I'm still wondering
what would happen if a signal occurred at that point and then signal
handler called some cancellable routine (such as write())?

	--david