From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 3798E383982B for ; Tue, 5 Apr 2022 15:24:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3798E383982B Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-284-a17QK2TcM_uH3wqk1lxasg-1; Tue, 05 Apr 2022 11:24:45 -0400 X-MC-Unique: a17QK2TcM_uH3wqk1lxasg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B7D72833942; Tue, 5 Apr 2022 15:24:44 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7AC18C57963; Tue, 5 Apr 2022 15:24:43 +0000 (UTC) From: Florian Weimer To: Mark Wielaard Cc: libcurl development , Catalin Raceanu , elfutils-devel@sourceware.org Subject: Re: Using libcurl in another library, when/if to call curl_global_init? References: <1ea188affb14c7b55ec1d54fe95627d83e730bb4.camel@klomp.org> Date: Tue, 05 Apr 2022 17:24:41 +0200 In-Reply-To: (Mark Wielaard's message of "Thu, 31 Mar 2022 15:19:51 +0200") Message-ID: <874k37y2me.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 15:24:51 -0000 * Mark Wielaard: > Hi, > > 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 problem is that every caller of pthread_once needs to use the same pthread_once_t synchronization object, so you still have the same problem. I strongly believe that library-safe code needs to perform lazy initialization, that is, initialize the library on first use, and do that in a thread-safe manner. It solves the synchronization issue between different users of the API, and it's the only way to report errors properly (for example, a failure in an ELF constructor can only be reported via process termination). At least on Linux, the need to support multiple different threading libraries is a thing of the past. Thanks, Florian