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
next prev parent 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).