From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id CECE51F4D7 for ; Tue, 24 May 2022 06:40:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233726AbiEXGkJ (ORCPT ); Tue, 24 May 2022 02:40:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233019AbiEXGkF (ORCPT ); Tue, 24 May 2022 02:40:05 -0400 X-Greylist: delayed 485 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Mon, 23 May 2022 23:40:02 PDT Received: from silly.haxx.se (silly.haxx.se [159.253.31.95]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BFFC497282 for ; Mon, 23 May 2022 23:40:02 -0700 (PDT) Received: by silly.haxx.se (Postfix, from userid 1001) id CD3D961F1B; Tue, 24 May 2022 08:31:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by silly.haxx.se (Postfix) with ESMTP id CC6E78035F; Tue, 24 May 2022 08:31:55 +0200 (CEST) Date: Tue, 24 May 2022 08:31:55 +0200 (CEST) From: Daniel Stenberg To: Junio C Hamano cc: Johannes Schindelin , git@vger.kernel.org, Michael J Gruber Subject: Re: [PATCH] http.c: clear the 'finished' member once we are done with it In-Reply-To: Message-ID: References: <3f0e462e86625a3c253653e4a4eefabcd8590bf9.1651859773.git.git@grubix.eu> X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Mon, 23 May 2022, Junio C Hamano wrote: >> It calls into cURL, which I suspect has a multi-threaded mode of >> operation, > > https://curl.se/libcurl/c/threadsafe.html ;-) > > My understanding is that what we have is pretty much select() driven > single-threaded multi-fd transfer. Confirmed. libcurl *can* use threads (if built that way), but the only use it has for such subthreads is for resolving host names. libcurl, its API and its callbacks etc always operate in the same single thread. -- / daniel.haxx.se