public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Tom Tromey <tom@tromey.com>, binutils@sourceware.org
Subject: Re: [PATCH 3/3] Add minimal thread-safety to BFD
Date: Wed, 1 Nov 2023 12:45:41 +0000	[thread overview]
Message-ID: <9471e18d-f7cf-4630-a8c4-7a76d822c83c@redhat.com> (raw)
In-Reply-To: <20231026191435.204144-4-tom@tromey.com>

Hi Tom,

> This patch provides some minimal thread-safety to BFD.
> 
> The BFD client can request thread-safety by providing a lock and
> unlock function.  The globals used during BFD creation (e.g.,
> bfd_id_counter) are then locked, and the file descriptor cache is also
> locked.  A function to clean up any thread-local data is now provided
> for BFD clients.
> 
> 	* bfd-in2.h: Regenerate.
> 	* bfd.c (lock_fn, unlock_fn): New globals.
> 	(bfd_thread_init, bfd_thread_cleanup, bfd_lock, bfd_unlock): New
> 	functions.
> 	* cache.c (bfd_cache_lookup_worker): Use _bfd_open_file_unlocked.
> 	(cache_btell, cache_bseek, cache_bread, cache_bwrite): Lock
> 	and unlock.
> 	(cache_bclose): Add comment.
> 	(cache_bflush, cache_bstat, cache_bmmap): Lock and unlock.
> 	(_bfd_cache_init_unlocked): New function.
> 	(bfd_cache_init): Use it.  Lock and unlock.
> 	(_bfd_cache_close_unlocked): New function.
> 	(bfd_cache_close, bfd_cache_close_all): Use it.  Lock and unlock.
> 	(_bfd_open_file_unlocked): New function.
> 	(bfd_open_file): Use it.  Lock and unlock.
> 	* doc/bfd.texi (BFD front end): Add Threading menu item.
> 	* libbfd.h: Regenerate.
> 	* opncls.c (_bfd_new_bfd): Lock and unlock.
> 	* po/bfd.pot: Regenerate.

I have one concern about this patch:


> +typedef void (*bfd_lock_unlock_fn_type) (void);

Given that we are dealing with client provided locking and unlocking
functions, I feel that the client might want to be able to reference
a data structure of their own performing these actions.  (I am not
hugely familiar with locking and unlocking functions, so maybe I am
mistaken here).  I also wonder if the functions might be interested
in the BFD being locked.  Thus I think that the typedef might be
better specified as:

  typedef void (* bfd_lock_unlock_fn_type) (bfd *, void *);

I also wonder if the functions should be allowed to fail, in which
case the typedef would be:

  typedef bool (* bfd_lock_unlock_fn_type) (bfd *, void *);

Given all of that the init function would have to be extended to take
a data pointer:

> +void
> +bfd_thread_init (bfd_lock_unlock_fn_type lock, 
                     bfd_lock_unlock_fn_type unlock,
                     void * data)
> +{
> +  lock_fn = lock;
> +  unlock_fn = unlock;
      lock_data = data;
> +}

Also - should this function let the caller know if a previous set
of lock/unlock functions had been registered, or if there was a problem
registering them ?  (For example is it OK to have a lock function but
not an unlock function ?)  ie:

   bool
   bfd_thread_init (bfd_lock_unlock_fn_type lock,
                    bfd_lock_unlock_fn_type unlock,
                    void * data)
   {
      bool ret = lock_fn == NULL && unlock_fn == NULL;

      lock_fn = lock;
      unlock_fn = unlock;
      lock_data = data;

      ret &= (lock_fn != NULL && unlock_fn != NULL) || (lock_fn == NULL && unlock_fn == NULL);
      return ret;
   }


And of course the bfd_lock and bfd_unlock would need to be updated as well, eg:

> +bool
> +bfd_lock (bfd * abfd)
> +{
> +  if (lock_fn != NULL)
> +    return lock_fn (abfd, lock_data);
      return true;
> +}

What do you think ?

Cheers
   Nick


  reply	other threads:[~2023-11-01 12:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-26 19:07 [PATCH 0/3] Threads and BFD Tom Tromey
2023-10-26 19:07 ` [PATCH 1/3] Make _bfd_error_buf static Tom Tromey
2023-11-01 12:27   ` Nick Clifton
2023-10-26 19:07 ` [PATCH 2/3] Make various error-related globals thread-local Tom Tromey
2023-11-01 12:28   ` Nick Clifton
2023-10-26 19:07 ` [PATCH 3/3] Add minimal thread-safety to BFD Tom Tromey
2023-11-01 12:45   ` Nick Clifton [this message]
2023-11-01 20:08     ` Tom Tromey
2023-11-01 20:48       ` Tom Tromey
2023-11-02 12:14         ` Nick Clifton
2023-11-03 23:10           ` Tom Tromey
2023-11-01 12:26 ` [PATCH 0/3] Threads and BFD Nick Clifton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9471e18d-f7cf-4630-a8c4-7a76d822c83c@redhat.com \
    --to=nickc@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).