This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


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: exception handling predicament


On Fri, Aug 19, 2011 at 08:23:19AM -0700, David Miller wrote:
> It is not only aio_suspend.c, here are a few others I was able to spot
> very quickly.  There are probably several others:
> 
> nptl/sysdeps/unix/sysv/linux/sem_wait.c

Well,
      /* Enable asynchronous cancellation.  Required by the standard.  */
      int oldtype = __pthread_enable_asynccancel ();

      err = lll_futex_wait (&isem->value, 0,
                            isem->private ^ FUTEX_PRIVATE_FLAG);

      /* Disable asynchronous cancellation.  */
      __pthread_disable_asynccancel (oldtype);

means any insn in between the two calls might throw, while the two calls
will be surely marked in .gcc_except_table as belonging to the right
exception region.  So, I agree in these cases we either should use
the external calls that nptl/pthread_*.c is using that queue cleanup
handlers into thread local chain, or the pthread_cleanup_push/pop needs
to call a noinline function which does the actual enabling/disabling of
async exceptions.  -fnon-call-exceptions probably doesn't help, because
it only considers a couple of insns to be able to throw (those that may trap
or calls).  GCC doesn't have a -fasynchronous-exceptions option which would
consider every single insn to be able to trap (and I think it would be hard
to implement it).

	Jakub


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