public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: libcurl development <curl-library@lists.haxx.se>
Cc: elfutils-devel@sourceware.org
Subject: Re: Using libcurl in another library, when/if to call curl_global_init?
Date: Sat, 23 Apr 2022 00:14:36 +0200	[thread overview]
Message-ID: <YmMozKQckY0Mmrtj@wildebeest.org> (raw)
In-Reply-To: <YkWqdxmRuMHE2XnH@wildebeest.org>

Hi,

On Thu, Mar 31, 2022 at 03:19:51PM +0200, Mark Wielaard via curl-library wrote:
> On Thu, Mar 31, 2022 at 04:00:16PM +0300, Catalin Raceanu via curl-library wrote:
> > On 31-Mar-22 15:04, Mark Wielaard wrote:
> > > whether there is a thread-safe way to call
> > > curl_global_init at a later time (to get rid of the library constructor
> > > init function).
> > 
> > I believe that this is an exact fit for C==11's std::call_once(). Boost also
> > has an equivalent, that most likely predates the other, in case older c++
> > standard is used.
> 
> Thanks. Our library is pure C, but we can probably rely on
> pthread_once if it is allowable to call curl_global_init at a later
> time when multiple threads are already running. The reason we aren't
> doing that now is because the curl_global_init documentation
> explicitly states "You must not call it when any other thread in the
> program is running". But maybe we are interpreting the documentation
> too strictly?

Since it does seem we were interpreting the documentation a bit too
strictly I did propose a patch for elfutils that does lazy
initialization using pthread_once.

https://sourceware.org/pipermail/elfutils-devel/2022q2/004934.html

This makes sure we don't race against ourselves. And for programs
using our library we can assume they will call curl_global_init before
creating a multi-threaded environment and calling our own handle
initialization functions.

It would still be great if curl_global_init itself could be made
thread-safe to call.

Thanks,

Mark

  parent reply	other threads:[~2022-04-22 22:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-31 12:04 Mark Wielaard
     [not found] ` <b424b435-482d-7d24-4337-8ef7437ab05c@mega.nz>
2022-03-31 13:19   ` Mark Wielaard
2022-04-05 15:24     ` Florian Weimer
2022-04-22 22:14     ` Mark Wielaard [this message]
2022-04-05 15:36 ` Daniel Stenberg
2022-04-05 16:19   ` Mark Wielaard

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=YmMozKQckY0Mmrtj@wildebeest.org \
    --to=mark@klomp.org \
    --cc=curl-library@lists.haxx.se \
    --cc=elfutils-devel@sourceware.org \
    /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).