new syscall stub support for ia64 libc

[David Mosberger]

>>>>> On Mon, 17 Nov 2003 17:30:32 -0800, Ulrich Drepper <drepper@redhat.com> said:

  >> I don't see anything that would prevent NPTL from providing
  >> better async-cancel-safety, but juding by your response, it
  >> doesn't.

  Uli> Certainly not.  Since all this special handling makes the
  Uli> normal case slower.  Asynchronous cancellation is bad and
  Uli> fortunately rarely used, so no effort which slows down general
  Uli> code and which is necessary to support async cancel is worth
  Uli> it.

That makes sense.  Thanks for confirming.

  >> I still don't understand the interaction between signals and
  >> thread-cancellation and I couldn't find where this is being
  >> discussed in the standard.  Any pointers?

  Uli> What interaction?  Cancellation is implemented via signals.
  Uli> That should be obvious.

The one I mentioned: signal handler gets called in this code right
before the _IO_flockfile():

	    _IO_FILE *_IO_acquire_lock_file			\
	        __attribute__((cleanup (_IO_acquire_lock_fct)))	\
	        = (_fp);					\
	    _IO_flockfile (_IO_acquire_lock_file);

and then the signal handler calls write(), which ends up getting
cancelled.  What prevents this from happening?

	--david