[gccsdk] Thread-safety in C++ exception support code

Alex Waugh alex at alexwaugh.com
Fri Aug 3 22:29:04 BST 2007


"Ben Avison" <bavison at riscosopen.org> wrote:

> The root cause is that the run-time support routines from libgcc (defined in
> unwind-sjlj.c) are built in their non-thread-safe forms, because none of the
> build switched recognised in dthr.h were defined when it was built. This
> appears to apply to all builds off libgcc, application and module, UnixLib
> and SCL.
> 
> For UnixLib builds of libgcc, it would seem sensible to define the symbol
> _PTHREADS, in order to use the in-built pthreads implementation. However,
> I'm not sure where this is best performed, not being very familiar with the
> build process.

Thanks for this. I have added _PTHREADS to UnixLib builds of libgcc in
the 3.4 branch. I'll have a go at the trunk later.

> I have an additional requirement in that I'm building against the SCL and
> using my own threading library (one of the reasons being that I'm building
> a module, which isn't supported by UnixLib or its pthreads library). This
> isn't the first time I've been in this situation, and it may be of use to
> others in the future too, so I'd like to suggest that thread-safety is
> enabled for SCL builds too. I imagine that a set of UpCalls would be a
> quite RISC OS-y way to decouple the runtime support functions from the
> threading library in use (if any). But as you can probably tell, I've not
> gone very far down the design path just yet.

I'd hope there isn't going to be a proliferation of threading libraries
duplicating each other, and needing support.
How fast are upcalls? Given how often destructors may be called, it
could be quite an impact.


Alex

-- 
Alex Waugh                                           alex at alexwaugh.com

PHP, Roots, Subversion, WebJames and more from http://www.alexwaugh.com/



More information about the gcc mailing list