On 08/26/2016 01:49 PM, Corinna Vinschen wrote:
> On Aug 26 13:18, Corinna Vinschen wrote:
> 
> Apart from these minor bits and pieces, I really like this new
> pathfinder class, btw.

Thank you! :)

While at it: Combining dlopen thoughts with the "forkables" background
around replacing dlls-in-use leads me to this thought for redundant
calls of dlopen:

As we've already agreed that GetModuleHandleEx might make sense,
I'm thinking whether pathfinder could be useful even for calling
GetModuleHandleEx before actually testing for the existing file.

First, we need to agree on which search order is correct for a
specific (redundant) dlopen usage. IMO, this should be for:

dlopen ("libz.so"):
  1) GetModuleHandleEx ("libz.so")
  2) GetModuleHandleEx ("cygz.dll")
  3) GetModuleHandleEx ("libz.dll")
  4) path_conv.exists-based only, as with current pathfinder

dlopen ("/usr/lib/libz.so"):
  1) GetModuleHandleEx ("\winpath\of\usr\bin\libz.so")
  2) GetModuleHandleEx ("\winpath\of\usr\bin\cygz.dll")
  3) GetModuleHandleEx ("\winpath\of\usr\bin\libz.dll")

  4) GetModuleHandleEx ("\winpath\of\usr\lib\libz.so")
  5) GetModuleHandleEx ("\winpath\of\usr\lib\cygz.dll")
  6) GetModuleHandleEx ("\winpath\of\usr\lib\libz.dll")

  7) path_conv.exists ("\winpath\of\usr\bin\libz.so")
  8) path_conv.exists ("\winpath\of\usr\bin\cygz.dll")
  9) path_conv.exists ("\winpath\of\usr\bin\libz.dll")

 10) path_conv.exists ("\winpath\of\usr\lib\libz.so")
 11) path_conv.exists ("\winpath\of\usr\lib\cygz.dll")
 12) path_conv.exists ("\winpath\of\usr\lib\libz.dll")

Thing is that with the latter (predefined path), in a first iteration
we need the same filenames to test for already-loaded as in a second
iteration where we test for real files.

Attaching a patch draft for a pathfinder criterion interface...

Thoughts?

/haubi/