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
>> 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 +
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.