From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) by sourceware.org (Postfix) with ESMTPS id 2CB47388982E for ; Mon, 7 Jun 2021 21:54:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2CB47388982E Received: by mail-qv1-xf34.google.com with SMTP id l3so2684449qvl.0 for ; Mon, 07 Jun 2021 14:54:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AXzuMYiP/PXRv+xpcA7FR4+rE9WjTHRc1KVJmahUusQ=; b=MG552nPX/izm0psyapmL7gnQXa/0gGcXRM1sAmGGl85albpFLYGtd7UOQlPYJwDKrS u/nqzEy3z5mSzgq4z2SGE6KKhemRGRkRJ+XCicDrLRfTlyFC4csOgiUpFwnHDyO0Jzi/ SdaA9WWEXTbQj4aiJrtMcoCYPTFD6k12bFYYBEpVacjKO+RYboEbpkAeAAzCXmjvvABc yv87+rDttMWvyLa6+b91AxKK27H+Gz0lJBPkVfbq6NoUTa6iuheLomvcQra1HyxZC5Cx esZ0845/iGR9iauQH9TCn8DOaPtDc1Yf0O+eB45xrklW0LeCI+R+B27MWlXPs4ChlmWJ WOWA== X-Gm-Message-State: AOAM532P8Is1Be8SndsabVECbbVboz0+ZUovvzIlWD1WfpU6Uk5+cra8 eDewfxiklY+R3NRtusELSzMHM2bndpKzvA== X-Google-Smtp-Source: ABdhPJyL7PA42aY+E2VS8fD7hm3N8O2K50ZeZmZ5PgCmail+TO1UIlrWY4FxKtthvC7lNG1IpYX6Og== X-Received: by 2002:a05:6214:76b:: with SMTP id f11mr20451269qvz.8.1623102839513; Mon, 07 Jun 2021 14:53:59 -0700 (PDT) Received: from [192.168.1.4] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id p13sm175141qkg.80.2021.06.07.14.53.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Jun 2021 14:53:59 -0700 (PDT) From: Adhemerval Zanella Subject: Re: inode-based dlopen caching To: "Soni L." , Libc-help References: Message-ID: <62ae59a3-cada-f56c-5f34-5e0cc26ff4d4@linaro.org> Date: Mon, 7 Jun 2021 18:53:57 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 21:54:01 -0000 On 05/06/2021 10:59, Soni L. via Libc-help wrote: > Currently dlopen caching is based on filenames, it'd be nice if it was > based on inodes to support better "re"loading (aka loading a new module > with the same name because unloading modules with threads is never a > good idea). This is good for stuff that deals with plugins. > What do you mean by 'caching' in this scenario? glibc does not maintain a cache of loaded libraries, different than other implementation it does try to unload the library on dlclose (there are cases where it is not readily possible due dependency chains). And I am not seeing how inote-bases dlopen really helps here, if inode changes means that file was potentially changed (so you will need to proper dclose it). I think using filenames is in fact the proper way here, since Linux does the hard lifting of the inode cache and provide fast file access and mmap support for shared libraries.