This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/4] dlopen: switch to new pathfinder class


On 09/08/2016 01:58 PM, Corinna Vinschen wrote:
> On Sep  2 13:36, Michael Haubenwallner wrote:
>> On 09/02/2016 10:52 AM, Corinna Vinschen wrote:
>>> On Sep  2 10:05, Michael Haubenwallner wrote:
>>>> Moving the allocator into pathfinder would work then, but still the
>>>> tmp_pathbuf instance to use has to be provided as reference.
>>>
>>> Hmm, considering that a function calling your pathfinder *might*
>>> need a tmp_pathbuf for its own dubious purposes, this makes sense.
>>> That could be easily handled via the constructor I think:
>>>
>>>   tmp_pathbuf tp;
>>>   pathfinder finder (tp);
>>>
>>> Still, since I said I'm willing to take this code as is, do you want me
>>> to apply it this way for now or do you want to come up with the proposed
>>> changes first?
>>
>> As I do prefer both pathfinder and vstrlist to not know about tmp_pathbuf
>> in particular but a generic memory provider only: Yes, please apply as is.
> 
> Done, minus patch 4.

Then my original problem with dlopen isn't fixed yet, where some application
code within /opt/app/bin/app.exe does dlopen(libAPP.dll), currently finding
/usr/bin/libAPP.dll although app.exe linked against /opt/app/bin/libAPP.dll.

However, thank you anyway!

> I still think that there should be only a single
> pathfinder object and the rest encapsulated within and called via some
> pathfinder member function.  I'll look into it later this year.

A thought to avoid the extra tmp_pathbuf_allocator class:
Have cygmalloc.h (or similar) declare the allocator interface,
to allow for tmp_pathbuf to implement it by itself.

The complete idea is to have another allocator implementation using
cmalloc+cfree, as well as one more using malloc+free. Probably there
is use for another one using VirtualAlloc+VirtualFree as well.

Then even path_conv might utilize the allocator interface, using the
cmalloc+cfree implementation (provided by cygmalloc.h) by default...

/haubi/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]