On 10 February 2012 18:20, Rainer Orth wrote:
> Jon,
>
>> On 10 February 2012 14:48, Rainer Orth wrote:
>>> I've also noticed one feature of your patch that I don't like:
>>> __GTHREAD_{MUTEX,COND}_INIT_FUNCTION ignore the return values of
>>> pthread_{mutex,cond}_init_function instead of passing them on as all
>>> other gthr-posix.h functions do. This might lead to bad error handling,
>>> and my previous patch (based on an older version of yours you had
>>> attached to the PR) changed them to return int instead. I suppose
>>> changing this now is out of question, and this is left as 4.8 material.
>>
>> I didn't like that feature of the patch much either, but the signature
>> of the mutex_init function is specified in gthr.h:
>>
>> __GTHREAD_MUTEX_INIT_FUNCTION
>> some systems can't initialize a mutex without a
>> function call. On such systems, define this to a
>> function which looks like this:
>> void __GTHREAD_MUTEX_INIT_FUNCTION (__gthread_mutex_t *)
>>
>> The recursive one says it should have the same signature, and I (maybe
>
> I don't see this, neither in gthr.h nor in gthr-posix.h.
lines 54-62 in http://gcc.gnu.org/viewcvs/trunk/libgcc/gthr.h?view=markup
>> wrongly) assumed the cond_init one should too.
>
> I don't think this is cast in stone: the gthr*.h headers aren't
> installed in a public place and aren't considered an external interface
> to the best of my knowledge, so it should be possible to change.
>
> Currently, __GTHREAD_MUTEX_INIT_FUNCTION is only used in libgcc,
> libgfortran, and libstdc++ (and __GTHREAD_COND_INIT_FUNCTION only in
> libstdc++), so changing the 13 calls is doable.
Private ports which provide their own gthr header (I think they're
rare, but do exist) would need to modify their functions to return an
integer - but at least it would be a compile-time failure so they'd
know to change it.
