This is the mail archive of the mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: new syscall stub support for ia64 libc

>>>>> On Mon, 17 Nov 2003 10:07:34 -0800, Ulrich Drepper <> 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:


	#  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);


	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())?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]