The following reply was made to PR kern/131597; it has been noted by GNATS.
From: David Xu <[email protected]> To: John Baldwin <[email protected]> Cc: Kostik Belousov <[email protected]>, [email protected], [email protected], [email protected] Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Tue, 14 Sep 2010 14:00:13 +0000 John Baldwin wrote: > Do we know of any use cases where libunwind would be used from a signal > handler? Could we instead simply declare it to be an unsafe API in a signal > context? longjmp(3) isn't safe in a signal context and throwing exceptions > in a signal handler is undefined, so declaring libunwind to similarly be > unsafe may be fine. > It is true that libunwind would be used from a signal handler. In fact, when I was working on stack unwinding support for libthr, I found it. The reason I was trying to do it is that I want to let C++'s on-stack object to be destructed when thread is exited, otherwise, C++ program can not use pthread cancellation feature, the pthread cancellation calls pthread_exit(), and the function should unwind the thread's stack for C++ like language, otherwise the programs leak resource. In head branch, things are improved, for defer-mod, thread cancellation is called from in-place context, but for asynchronous mode, thread cancellation is called from a signal handler, the SIGCANCEL hanlder, so the libunwind needs to dig out the saved context and unwind the interrupted stack. A very bad news is libunwind only did unwind-through-signal-stack for linux, nothing has been done for FreeBSD and others, code has been found here: /usr/src/contrib/gcc/config/i386/linux-unwind.h I even have a patch for FreeBSD x86 to support the unwind-through-signal-stack, but I have not fully tested it. http://people.freebsd.org/~davidxu/patch/unwind.patch You can say this is a crazy idea, but they did it. >>> OTOH, I'm not sure why libthr needs to use non-standard lock hooks at >>> this point as they don't seem to be markedly different from the ones >>> rtld uses. >> libthr locks provide exclusion both for other kernel-executed threads >> and signal handlers, while the rtld-default locks only protect against >> signal handlers and thus libc_r-style threads. > > Oh, bah. The rtld locks do use atomic operations that are thread safe, > but I missed that the 'oldsigmask' global needs to be per-thread. > In head branch, when program is linked with libthr, and created a thread, the libthr's rtld lock implementation is activated, performance should be improved, but otherwise, it is still slow for non-threaded C++ program. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
