[cxx-abi-dev] One-time Construction API (3.3.2)

[Jason Merrill]

On Wed, 4 Aug 2004 22:45:21 -0700 (PDT), Dennis Handly <dhandly at cup.hp.com> wrote:

>>From: Jason Merrill <jason at redhat.com>
>>primarily because if construction of the object throws, we need to call
>>__cxa_guard_abort, but if destruction of any temporaries throws, we need to
>>call __cxa_guard_release.
>
> Hmm, we seem to do the same for both.  And it is left on the atexit list
> for the latter.

Doing the same for both is wrong, I think; once construction of the object
is complete, it's complete, whether or not the subsequent cleanup throws.

>>  To make this work, we need to do something like
>>if (__cxa_guard_acquire (&guard)) {
>
> You didn't optimize by checking the guard before calling
> _cxa_guard_acquire.

Yep, I left that out for brevity.

>>The flag is necessary to avoid non-nested overlapping EH regions.
>
> We don't use a flag.  We use try/catch:
>     try {
>         /* initialize */
>         __cxa_atexit(dtor);
>         __cxa_guard_release(&guard);
>     }
>     catch(...) {
>           __cxa_guard_abort(&guard);
>     }

Yes, here it looks like you incorrectly call abort rather than release if a
cleanup throws.

>>2.8 refers to "the first byte", while 3.3.2 refers to "the low-order
>>byte".  These are the same on little-endian targets, but not big-endian.
>
> Are you sure?  It says byte with lowest address.  Not low-order byte.
> First and lowest are the same for big-endian.

You're right, I was looking at an old copy of the ABI on my laptop; the
wording was fixed to be consistent in September 2002.

>>I've been thinking about how to implement the actual locking, and the best
>>I've come up with is to have the guard be an index into an array of mutexes
>
> We use one mutex for all statics.  The same one that synchronizes the
> __cxa_atexit list.

Yes, that's a much simpler solution, and I think reasonable.

>>with magic values for uninitialized and "creating mutex"; in the latter
>>case another thread that comes to it should just spin until it takes on
>>another value.
>
> We do use the second byte to handle (stop) recursion.  Though this seems
> flawed in that it won't wait until constructed.  :-(

I'm not sure what you mean.  If you already have a mutex, what are you
using the second byte for?

Jason