Add proxy_pool

[igchor]

a pool that forwards all (supported) requests to the memory provider.

[igchor]

Ok, I was debugging the windows failure and it looks like there is a problem with exporting global variables (like OPS vars).

Accordingly to the documentation: "Using __declspec(dllimport) is optional on function declarations, but the compiler produces more efficient code if you use this keyword. However, you must use __declspec(dllimport) for the importing executable to access the DLL's public data symbols and objects".

So, this means that we would need to define UMF_EXPORT like this:

#if defined(UMF_EXPORTS) && defined(UMF_SHARED_LIBRARY)
    #define UMF_EXPORT __declspec(dllexport)
#elif defined(UMF_SHARED_LIBRARY)
    #define UMF_EXPORT __declspec(dllimport)
#endif

but... then we have a problem when we build UMF as a static library because using __declspel(dllimport) on symbols from static library will result in linking failure (see here). To solve this users would need to define UMF_SHARED_LIBRARY in their application whenever linking with libumf as a shared library (or the other way around, define something for static library).

I don't think forcing users to define this is a good ideas to perhaps we could just avoid global variables altogether? Instead of global UMF_*_POOL_OPS variables we could just define functions that would return proper ops. @pbalcer @bratpiorka @vinser52 any thoughts?

[lplewa]

Ok, I was debugging the windows failure and it looks like there is a problem with exporting global variables (like OPS vars).

Accordingly to the documentation: "Using __declspec(dllimport) is optional on function declarations, but the compiler produces more efficient code if you use this keyword. However, you must use __declspec(dllimport) for the importing executable to access the DLL's public data symbols and objects".

So, this means that we would need to define UMF_EXPORT like this:

#if defined(UMF_EXPORTS) && defined(UMF_SHARED_LIBRARY)
    #define UMF_EXPORT __declspec(dllexport)
#elif defined(UMF_SHARED_LIBRARY)
    #define UMF_EXPORT __declspec(dllimport)
#endif

but... then we have a problem when we build UMF as a static library because using __declspel(dllimport) on symbols from static library will result in linking failure (see here). To solve this users would need to define UMF_SHARED_LIBRARY in their application whenever linking with libumf as a shared library (or the other way around, define something for static library).

I don't think forcing users to define this is a good ideas to perhaps we could just avoid global variables altogether? Instead of global UMF_*_POOL_OPS variables we could just define functions that would return proper ops. @pbalcer @bratpiorka @vinser52 any thoughts?

Imho solution is to use DEF file on Windows instead of dllexport. It's similar to linux map file, and it's hides windows mess from header.

[igchor]

Imho solution is to use DEF file on Windows instead of dllexport. It's similar to linux map file, and it's hides windows mess from header.

@lplewa +1 for using .def files but accordingly to https://learn.microsoft.com/en-us/cpp/build/reference/exports?view=msvc-170 this won't really solve the issue here:

"When you export a variable from a DLL by using a .DEF file, you do not have to specify __declspec(dllexport) on the variable. However, in any file that uses the DLL, you must still use __declspec(dllimport) on the declaration of data".

[lplewa]

Imho solution is to use DEF file on Windows instead of dllexport. It's similar to linux map file, and it's hides windows mess from header.

@lplewa +1 for using .def files but accordingly to https://learn.microsoft.com/en-us/cpp/build/reference/exports?view=msvc-170 this won't really solve the issue here:

"When you export a variable from a DLL by using a .DEF file, you do not have to specify __declspec(dllexport) on the variable. However, in any file that uses the DLL, you must still use __declspec(dllimport) on the declaration of data".

Windows....

Can we replace exported global variable with an exported "get" function, which returns global "nonexported" variable from dll?

[igchor]

Imho solution is to use DEF file on Windows instead of dllexport. It's similar to linux map file, and it's hides windows mess from header.

@lplewa +1 for using .def files but accordingly to https://learn.microsoft.com/en-us/cpp/build/reference/exports?view=msvc-170 this won't really solve the issue here:
"When you export a variable from a DLL by using a .DEF file, you do not have to specify __declspec(dllexport) on the variable. However, in any file that uses the DLL, you must still use __declspec(dllimport) on the declaration of data".

Windows....

Can we replace exported global variable with an exported "get" function, which returns global "nonexported" variable from dll?

Yeah, that was my idea as well - I think this should work (although I haven't tried that yet, and it's windows so anything is possible). I just wanted to ask first, and see if there's a better way.

[lplewa]

I will vote to switch to def files, and instead exporting variables, export getters.

[pbalcer]

I will vote to switch to def files, and instead exporting variables, export getters.

👍

[igchor]

Ok, I'll make a PR to replace all variables with getters. This is not strictly necessary for every variable since some of them are only in static libraries, e.g. disjoint_pool but I think it's better to be consistent + we may choose to build those libs as DLLs in future.