Re: [boost] [Boost-users] Boost.DLL formal review is ongoing

Subject: Re: [boost] [Boost-users] Boost.DLL formal review is ongoing
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2015-07-04 09:03:15

On 4 July 2015 at 11:38, Antony Polukhin <antoshkka_at_[hidden]> wrote:

> 2015-07-04 0:16 GMT+03:00 Klaim - Joël Lamotte <mjklaim_at_[hidden]>:
>>
>>
>> On 3 July 2015 at 15:50, Vladimir Prus <vladimir.prus_at_[hidden]> wrote:
>>>
>>> - What's your evaluation of
>>>   - Design
>>>
>>
>> I consider the solutions provided to solve each usual issue with plugin
>> systems to be simple
>> and clear, easy to use (as long as you understand what loading plugins
>> imply).
>>
>> Until I check in some complex cases, I think the design is very good.
>> The symbol name magic might be tricky to understand sometime but it's an
>> issue which is a side effect of providing
>> a simple tool to manage symbole names, so it's still good.
>>
>> One thing I was wondering: would it be possible to provide a way to load
>> shared libraries from
>> raw memory? Or does the OS APIs all requires that the library have to be
>> on a file sytem?
>>
>
> Unfortunately, there's no portable way to load libraries from raw memory.
> However you can always mount a filesystem that directly maps to memory (for
> example Tmpfs on Linux) and store your data in there. This may look like a
> big performance overhead, but actually loading a shared library takes much
> time so you won't probably notice the overhead of additional create_file +
> memcpy.
>

It's ok, the solution to write a shared library in the the filesystem
before loading it is what Ihave been doing so far and it works well.
I was just wondering if it was possible with memory. :)
If the plugin is in an archive file, I have to extract it in a temporary
directory before loading it, which is what I would like to avoid,
but it seems unavoidable.

>
> If you're planing this feature to write interpreters\JIT compillers and
> you just need a place to store end execute generated native code, then
> Boost.Interprocess's memory mapped files fill probably suit you better.
> Shared libraries contain a lot of headers, helper data for load and a bunch
> of other stuff that would be really hard to generate.
>

I don't write an interpreter (I'm really just managing plugins) but I
didn't know that, it seems useful in some other contexts.
Thanks for the pointer.