[Mono-dev] [PATCH] Make mono_dl_register_library into a fallback

[Michael Hutchinson]

On Fri, Jul 2, 2010 at 12:38 PM, Michael Hutchinson
<m.j.hutchinson at gmail.com> wrote:
> On Fri, Jul 2, 2010 at 6:18 AM, Paolo Molaro <lupus at ximian.com> wrote:
>> On 07/01/10 Michael Hutchinson wrote:
>>> The mono_dl_register_library function can currently be used to
>>> register P/Invoke mappings for platforms that do not have a dynamic
>>> linker. The attached patch makes it also function as a fallback when
>>> the system's dynamic linker cannot resolve the library, so that it is
>>> always available to embedders.
>>>
>>> I'll also need to restore mono/utils/mono-embed.h to the public
>>> headers in the autotools build (but this patch was created using MSVC
>>> on Windows).
>>>
>>> OK to commit to trunk?
>>
>> This interface is not suitable as a fallback mechanism, it would be too
>> cumbersome to use and it's probably not ideal even for its intended
>> purpose. What about a callback registration system instead?
>
> The intended purpose, AFAIK, is to expose statically linked libraries
> to P/Invoke. That's what I'm using it for, and it's very
> straightforward to use this way. I have a trivial C# tool that
> reflects over the library with the P/Invokes and dumps the mappings to
> source files.
>
> My patch isn't intended to provide a generic dynamic linker fallback.
> It's meant to provide an easy way to P/Invoke statically linked
> libraries for all embedders, not just those on platforms without
> dynamic linkers.
>
>> It is more flexible as a fallback since it doesn't require to register
>> upfront all the possible names and load the all functions at startup.
>> It's likely better also for the original purpose when, for example,
>> even if dynamic linking is not possible it is possible to lookup a
>> symbol at runtime.
>> It opens up the possibility of also generating the code at runtime
>> (for redirecting some win32 p/invokes to winforms for example, or other
>> tricks).
>>
>> Something along these lines:
>>
>> typedef void* (*MonoDlFallbackLoad) (const char *name, int flags, char **err, void *user_data);
>> typedef void* (*MonoDlFallbackSymbol) (void *handle, const char *name, char **err, void *user_data);
>> typedef void* (*MonoDlFallbackClose) (void *handle, void *user_data);
>>
>> void mono_dl_register_fallback (MonoDlFallbackLoad load_func, MonoDlFallbackSymbol symbol_func,
>>                MonoDlFallbackClose close_func, void *user_data);
>>
>> The old interface could be easily implemented on top of this new one (though we
>> likely could drop it as well).
>
> That's certainly more flexible, but I'm not convinced it's necessary
> at this time without concrete use cases. If we're going to include the
> old interface anyway - else we make embedders responsible for
> reimplementing its functionality - then why not go this path for now,
> and reimplement it on top of the callbacks later?

Any comment on this? I'd really like to get this functionality merged
ASAP, as other people depend on it, and the patch is getting stale.

-- 
Michael Hutchinson
http://mjhutchinson.com