[gccsdk] Thread-safety in C++ exception support code
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 Waugh alex at alexwaugh.com
PHP, Roots, Subversion, WebJames and more from http://www.alexwaugh.com/
More information about the gcc