Re: [boost] News about proposed Boost.Application library

Subject: Re: [boost] News about proposed Boost.Application library
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-07-30 05:27:31

On July 29, 2014 7:27:09 AM EDT, "Klaim - Joël Lamotte" <mjklaim_at_[hidden]> wrote:
>On Tue, Jul 29, 2014 at 12:19 PM, Joseph Van Riper <
>fleeb.fantastique_at_[hidden]> wrote:
>
>> On Tue, Jul 29, 2014 at 5:43 AM, Rob Stewart
><robertstewart_at_[hidden]>
>> wrote:
>>
>> > On July 29, 2014 3:39:16 AM EDT, "Klaim - Joël Lamotte" <
>> mjklaim_at_[hidden]>
>> > wrote:
>> > >I disagree. In my experience it would be more useful if it
>contained a
>> > >weak_ptr to the library, with a centralised system keeping all
>loaded
>> > >libraries alive and allowing the used to unload the library
>> > >explicitely.
>> > >The get_symbol return type would then be testable.
>> > >That way it is easier to find issues related to plugins and its
>still
>> > >possible for the user to prevent these issues at runtime.
>> >
>> > Please explain. Using a weak_ptr means each access must be tested,
>with
>> > synchronized access, to boot, versus assurance of validity with the
>> > shared_ptr.
>>
>> I think there are two scenarios.  In one, you're dynamically loading
>the
>> library, and you want it to remain in memory for the duration of the
>> application's run (you never intend to deallocate it until the
>application
>> is finished).

[snip]

That's nothing more than a collection of shared_ptr's to the dynamic library objects. It had no bearing on the objects returned by get_symbol().

>> However, there's another scenario where you dynamically load the
>library,
>> then deallocate it as soon as you're done with it (and where it is
>> important to do so).  For those scenarios, this centralized system of
>> keeping all loaded libraries alive is an unnecessary and unwanted
>burden.

[snip]

Indeed.

>> I think both scenarios can be supported by having an object that acts
>as
>> this centralized system which one may use if desired, while also
>having the
>> current system.

I think you've argued against such a "centralized system".

>Thanks this is exactly what I meant. I understand the first case
>but when using dynamically loaded libraries/modules, I more often
>endup in the second case (in particular when it's "plugins" of a tool
>or
>game or simulation engine, that need to be activated and deactivated
>when
>necessary).
>
>In the first case, you indeed want to make sure that the necessary
>libraries are always loaded.
>However in the second, you really need to have a way to be notified
>when
>calling something
>from an unloaded library. In this case, you might just trigger an
>error, or
>just do some logging
>or something. In my own cases I would not test the access returned
>object,
>because
>I assume that that object must not be accessible anymore once the
>related
>library is unloaded.
>Therefore, I consider this case a bug and want the application to crash
>early if that happen.

It sounds to me as if you're suggesting that you wouldn't actually use the weak_ptr, but instead simply call an unloaded function and live with the consequences.

>I was suggesting weak_ptr (wrapped inside something that looks like a
>std::function<>)
>so that the user decides if or not he wants to check if the library is
>still loaded before using the function.
>But personally I wouldn't.

I'm still at a loss to understand what you'd actually want get_symbol() to return to solve your use cases.

If the returned object holds a shared_ptr to the library, the library can't be unloaded until all such objects have been destroyed or until they are told to release their ref count. That is safer, however. Holding a weak_ptr instead implies a runtime check on each invocation, but doesn't prevent unloading the library. However, you've said you wouldn't use the weak_ptr, so I'm missing something.

___
Rob

(Sent from my portable computation engine)