From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) by sourceware.org (Postfix) with ESMTPS id C2E35385703F for ; Mon, 7 Jun 2021 22:50:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C2E35385703F Received: by mail-qk1-x72c.google.com with SMTP id c124so18410264qkd.8 for ; Mon, 07 Jun 2021 15:50:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=coMS8f7epOT7gJ0mhwx5BNq6j0vQDlMzq56A9qPqkMM=; b=EOSjsuSqkzHz5RoNXY8Vdc/HPrAZ7l9G0JqqLWCF4iqGXXYvMs0B1DCB1uT6wBgpjG mTcdGHEqU7ylxlqRjHAu8TykRHjp5IcMrW1f8Ue4o9ogE6ZowDatabRs6G2kTuazNcNS 6YrRFzQMV0/BGVsOn97q6kjNv+hR82LPV4heZxyKqqoIcMYqa751dmkWIUyPV5WVpHTN GQv9r67eEG9jSPWCS2FV5QJYuRQhTdXtJlI1wlzDy9nADepy3wFVN4Ejv466GbGTirij 8cA4D/Aog20mbOJyp4Bm+V7pmGQJC0xkd5gkNr/7ra7wuR8+wb1S3ejCPkE6C19NjJTS escQ== X-Gm-Message-State: AOAM530wbxL1NeiXUnxE2FsBeldi2hEiAuFu3X6sWkz2GNepMrRGiuIG iEXL76Pd1XstA+bJtPZ2ePcT3F/vsBU= X-Google-Smtp-Source: ABdhPJyTWkeJ9yPabP7H38Z+ONZZNneDPsbw0wVeDSbJqcw19iFx8ujQb9VK05h3fbTOEwYbQltp6g== X-Received: by 2002:a37:80c6:: with SMTP id b189mr18881813qkd.332.1623106245290; Mon, 07 Jun 2021 15:50:45 -0700 (PDT) Received: from ?IPv6:2804:431:d77d:670c::536f:6e69? ([2804:431:d77d:670c::536f:6e69]) by smtp.googlemail.com with ESMTPSA id a11sm4688510qti.3.2021.06.07.15.50.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Jun 2021 15:50:44 -0700 (PDT) Sender: "Soni L." Subject: Re: inode-based dlopen caching To: Adhemerval Zanella , Libc-help References: <62ae59a3-cada-f56c-5f34-5e0cc26ff4d4@linaro.org> From: "Soni L." Message-ID: Date: Mon, 7 Jun 2021 19:50:41 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <62ae59a3-cada-f56c-5f34-5e0cc26ff4d4@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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 22:50:47 -0000 On 2021-06-07 6:53 p.m., Adhemerval Zanella wrote: > > > 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. > You can't unload a dlopen that uses threads, at least not safely. So for all intents and purposes you can't unload it. Instead you need to tell it you're done with it, but not unload it, and load the new one. But that's the problem - the filename-based stuff means you can't load the new one.