From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17905 invoked by alias); 26 Aug 2016 11:18:40 -0000 Mailing-List: contact cygwin-developers-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com Received: (qmail 17877 invoked by uid 89); 26 Aug 2016 11:18:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-101.5 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: drew.franken.de Received: from mail-n.franken.de (HELO drew.franken.de) (193.175.24.27) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 26 Aug 2016 11:18:29 +0000 Received: from aqua.hirmke.de (aquarius.franken.de [193.175.24.89]) (Authenticated sender: aquarius) by mail-n.franken.de (Postfix) with ESMTPSA id 28692721E280D for ; Fri, 26 Aug 2016 13:18:25 +0200 (CEST) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by aqua.hirmke.de (Postfix) with ESMTP id 59F7A5E0378 for ; Fri, 26 Aug 2016 13:18:24 +0200 (CEST) Received: by calimero.vinschen.de (Postfix, from userid 500) id 4C2DDA805F5; Fri, 26 Aug 2016 13:18:24 +0200 (CEST) Date: Fri, 26 Aug 2016 11:18:00 -0000 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: About the dll search algorithm of dlopen (patch-r3) Message-ID: <20160826111824.GQ9783@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <574EF07B.1060806@ssi-schaefer.com> <20160601201748.GI11431@calimero.vinschen.de> <57B735D5.4070401@ssi-schaefer.com> <57B7362D.8060707@ssi-schaefer.com> <20160820193243.vbmpfjc5mjdhrndh@calimero.vinschen.de> <4d4481ce-c163-0ec9-29f5-59bbe13260fa@ssi-schaefer.com> <0963e74e-c963-a7f4-19e7-490b02f9393e@ssi-schaefer.com> <20160822183710.GA26590@calimero.vinschen.de> <025fabf1-e22c-246c-c3d6-3d2e5560ae39@ssi-schaefer.com> <20160826105908.GO9783@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="b/Q3JWIUAuLE0ZFy" Content-Disposition: inline In-Reply-To: <20160826105908.GO9783@calimero.vinschen.de> User-Agent: Mutt/1.6.2 (2016-07-01) X-SW-Source: 2016-08/txt/msg00013.txt.bz2 --b/Q3JWIUAuLE0ZFy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2458 On Aug 26 12:59, Corinna Vinschen wrote: > Hi Michael, >=20 > On Aug 25 19:48, Michael Haubenwallner wrote: > > Using tmp_pathbuf now, wrapped behind some trivial allocator - which > > might fit better somewhere else than to dlfcn.cc? > >=20 > > BTW: Is it really intended for tmp_pathbuf to have a single active > > instance (per thread) at a time? >=20 > Well, yes. tmp_pathbuf is meant to be initialized on function entry > (more or less, depends). It's supposed to exist only once per frame. > When the frame goes out of scope, the tmp_pathbuf usage counter is > restored to the values of the parent frame. >=20 > > + ATTENTION: Requesting memory from an instance of tmp_pathbuf breaks > > + when another instance on a newer stack frame has provided memory. */ >=20 > I don't understand this comment, though. tmp_pathbuf can be used > multiple times in the same thread stackm see other Cygwin functions. > What you can't do is to call a function, instantiate tmp_pathbuf, > allocate memory in the called function, and then use it in the caller. > Well, you *can* do that, but if you do this more than once, the same > memory region is reused. > That's the whole idea of tmp_pathbuf. > Temporary per-thread memory for the current frame and it's child frames > is allocated. If a deeper frame using tmp_pathbuf goes out of scope, > the memory is not free'd, but recycled next time temporary memory is > needed. The buffers are either 32K or 64K to matches the maximum long > path length. They are now used for any purpose where larger temporary > per-thread memory is needed, but providing temporary long path buffers > without killing the stack was their original purposes. So I also don't quite understand splitting off tmp_pathbuf_allocator. Why didn't you just include a tmp_pathbuf member into class pathfinder, kind of like this: /* pathfinder.h */ class pathfinder { tmp_pathbuf tp; [...] }; /* dlfcn.cc */ get_full_path_of_dll() { pathfinder finder (); /* Has a tmp_pathbuf member */ [...] finder.add_basename (basename); [...] finder.add_searchdir (dir, ...); return true; /* finder goes out of scope, so its tmp_pathbuf goes out of scope so tmp_pathbuf::~tmp_pathbuf is called and all is well. */ } ? Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --b/Q3JWIUAuLE0ZFy Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXwCWAAAoJEPU2Bp2uRE+g3pcP/2gDFystS37fer2LVMhFi0vr A3pqzVkh2CbFnzbuped3lxP9zqBlBPkAGKxS5Cqeaz8eL08NksuiziOD+L8UEGiL 9Zn/PSFAbjCo6DMwJubrkV17fz8HR1x/krca4TwdjZrdYG8X2eohv8TgeC1tFvsZ AJXC2DqZ9FXi65XtnLL8KYwk0rd0IkfoNKNG+o237JcWmpO901qXEDc4xF3iXB0x PMeQhHAgjvo4PE8V1potUWAuhqTDFNcfV2gplJv7Wf8nKCmD0MjIhHXm1ov5m0RB 439aAHkoWJl4BOsqv3lcVtVB4CR+zh7iP1+QfGonsSUNPn9Ogv2Jf4PGP6FElRsN vIGK9jMynDaC3uLrpGheMvmC5O3VW8VT6jwLsEG6YfZkyn4Y1d7m3CxaRslnO9le razpojDv7C2ou9BEdYcSwH/ybCMfrdC2F9iaquhreBDFNbl/fwVOrJ965yA3ZZ9i O5E7Jwt2+uC/6fkx7SqfQokIeVZgSK0D8wzKJ5gGeRgJGDak4HLGK6yZP9o9c2Ra eOGej70Nik7gprrokdoi1U8q+od36oVtUMpP2xa51FnKFtn3thRX21UjL1C6tizn smJ50uULQI/dBiwaSWVqiWh4+wjeWRa1aKvmCOs+drT4UgNjmENFAUGSLkSwSevx WgU2qDKwyJXPwTPdcUVz =tnW1 -----END PGP SIGNATURE----- --b/Q3JWIUAuLE0ZFy--