From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) by sourceware.org (Postfix) with ESMTPS id 8549B3857023 for ; Tue, 8 Jun 2021 18:10:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8549B3857023 Received: by mail-qk1-x72b.google.com with SMTP id u30so21090994qke.7 for ; Tue, 08 Jun 2021 11:10:07 -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:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EU3nsNjBemA+KrpitNv1pjhtaioG5Ex/sH5C0EwHXUQ=; b=FmXEX83nVxL0fjr61Ceug/uFr1Ld21r8OmElVWMDx2QK+BQHIPJCLneNetIdB47KC/ dY3j8Zd0fU0/7cXAhB5UypMszNVkvTeg5Lnpg24Rr+vRwLzNquSB5LfVnIfmjZJ3Zf8S Lfg6kCfuTKh1oFlRrAiXtaIgLHb1zTuFurIxGbQ04pNo7i7hgp8yHyDDoW39n5j9Lg1D FwE6EpAhXPWLspbbAzYk3hd4VPf0fGhehG9p6o6SQGmTbdHIza7HYCbNjuxi8rouLadI u6MtWb/jX6tURkeFzsws2g9Y6KlRyP9Tx7cbs2Sl1g2/qJ9Hm4kZNFRE3+tiiD8H7wEX hqxw== X-Gm-Message-State: AOAM533Qhh6gyJs8k0KHIKkUB0jcUNeNrmrQ8YiWr4Vtr2omzqeDLJnU 6ejRVe/UKsrZcn++gTHcEDKecpDmPTE= X-Google-Smtp-Source: ABdhPJxo8hEaV9Rot5SEr0wx5FSUplzfKcVYrH/4aXlpavuBJ+Utml4vmIN22f3sj73J9rkq0/ybtA== X-Received: by 2002:a05:620a:2007:: with SMTP id c7mr9238406qka.480.1623175806979; Tue, 08 Jun 2021 11:10:06 -0700 (PDT) Received: from ?IPv6:2804:431:d77d:670c::536f:6e69? ([2804:431:d77d:670c::536f:6e69]) by smtp.googlemail.com with ESMTPSA id m19sm6095605qtp.93.2021.06.08.11.10.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Jun 2021 11:10:06 -0700 (PDT) Sender: "Soni L." Subject: Re: inode-based dlopen caching To: Florian Weimer , Adhemerval Zanella Cc: Libc-help References: <87zgw09tww.fsf@oldenburg.str.redhat.com> <0242da65-0563-d03d-2ba7-5318c2a6c010@linaro.org> <87r1hc9ssx.fsf@oldenburg.str.redhat.com> From: "Soni L." Message-ID: Date: Tue, 8 Jun 2021 15:10:02 -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: <87r1hc9ssx.fsf@oldenburg.str.redhat.com> 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: Tue, 08 Jun 2021 18:10:08 -0000 On 2021-06-08 2:20 p.m., Florian Weimer via Libc-help wrote: > * Adhemerval Zanella: > >> But my main reservation with this is the idea of reload the new module >> is, although the symbol resolution is a different namespace, it still >> share the same process resources. It would require a lot of careful >> code within the library so it can run with multiple instances, we see >> the potential issues with our static dlopen support. > > It would work quite well for a lot of stateless JNI wrappers or Python > extensions, though. That alone looks like a relevant use case to me. > > Thanks, > Florian > The motivating use-case is hexchat plugins. Especially when they're written in Rust. Rust is supposed to provide memory safety but some edge-cases with dlopen break that, like truncating the shared library, or closing a shared library that has spawned threads.