Some operating system, for example RTEMS, may fail to create a POSIX key if not configured with enough resources. The lack of any error reporting in __eh_globals_init::__eh_globals_init() means exceptions are silently switched from thread safe to not being thread safe and this is not a concern for RTEMS. A way to report errors would be welcomed by RTEMS. We could hook this is a fatal error so the user is aware there is a critical issue that needs to be addressed. Thanks Chris
(In reply to Chris Johns from comment #0) > Some operating system, for example RTEMS, may fail to create a POSIX key if > not configured with enough resources. The lack of any error reporting in > __eh_globals_init::__eh_globals_init() means exceptions are silently > switched from thread safe to not being thread safe and this is not a concern > for RTEMS. I assume this is a typo and you mean this *is* a concern for RTEMS? :-) > A way to report errors would be welcomed by RTEMS. We could hook this is a > fatal error so the user is aware there is a critical issue that needs to be > addressed. I agree there should be some code to deal with the error there. This seems like a specific example of the broader problem you described in PR 60645.
(In reply to Jonathan Wakely from comment #1) > (In reply to Chris Johns from comment #0) > > Some operating system, for example RTEMS, may fail to create a POSIX key if > > not configured with enough resources. The lack of any error reporting in > > __eh_globals_init::__eh_globals_init() means exceptions are silently > > switched from thread safe to not being thread safe and this is not a concern > > for RTEMS. > > I assume this is a typo and you mean this *is* a concern for RTEMS? :-) > Yes, sorry about that. > > A way to report errors would be welcomed by RTEMS. We could hook this is a > > fatal error so the user is aware there is a critical issue that needs to be > > addressed. > > I agree there should be some code to deal with the error there. > > This seems like a specific example of the broader problem you described in > PR 60645. It is similar and I think a more critical issue. Thread-safe exceptions is something users expect to be working if there is no error. Reviewing the code a little more I am confused about the detail of how it works. Is it reasonable to assume the static constructor needs to be called before any thread local exceptions are thrown? We call constructors from the initial thread with the kernel up and running and user static constructors could start threads and these could raise exceptions.