[PATCH 3/3] Add minimal thread-safety to BFD

[Nick Clifton]

Hi Tom,

> Nick> typedef bool (* bfd_lock_unlock_fn_type) (bfd *, void *);
> 
> Tom> I suppose the BFD callers can just return if these fail.
> 
> Well, I started on this change, but I am not sure about it now.
> 
> cache_btell doesn't seem to have any way to even report an error.  So,
> I'm not sure what to do there.  Ignoring the failure is no good.

It could return "(ufile_ptr) -1".  This would be somewhat inline with
how ftell() behaves.


> Or, consider things like cache_bseek.  Handling a failure of bfd_lock is
> easy, but there's an unlock at the end:
> 
>    int result = _bfd_real_fseek (f, offset, whence);
>    bfd_unlock ();
>    return result;
> 
> If that fails should this really return -1?

Yes.

If the unlock has failed then something pretty bad must have happened and
it would not be a good idea to let the code carry on as if everything was
OK.


   Similarly for cache_bwrite,
> etc.

Yes - the same for these - if the lock or unlock fail then we should assume
the worst and try to return to the client as cleanly as possible.


> On the other hand, I don't think these things really can fail.  Like,
> pthread_mutex_lock/unlock failures modes all are basically programming
> errors.  So this may argue for just "doing anything".  Or we could
> declare these to be infallible.

I agree that they are unlikely to fail.  But being paranoid never hurts.
Since the caller is implementing the locks they can always choose to
just return "true" no matter what.  But if we do not support a failure
mode then one day someone, somewhere is bound to complain...


> Let me know what you'd prefer.

Be safe, be paranoid, and let the client decide whether their code can or
cannot fail.

Cheers
   Nick