[Clam-devel] COMMIT 11822 - Re: Faust support - plugins dynamic reloading

[Natanael Olaiz]

El 08/04/2008 01:20 PM, Pau Arumí escribió:
> On dl, 2008-08-04 at 12:12 +0200, David García Garzón wrote:
>   
>> El Monday 04 August 2008 11:15:20 Pau Arumí va escriure:
>>     
>>>> LAZY is needed there. It checks for a given symbol that is only present
>>>> on Ladspa plugins to avoid loading a dynamic lib that is not a ladspa.
>>>>         
>>> BTW, are we still trying to open _any_ file? We should restrict
>>> to .so, .dylib and .dll, and save time (and traces).
>>>
>>> Another related feature: as Hernan suggested, we should support "reload
>>> clam plugins" from NE.  I think Natanael can code this with the eyes
>>> closed :-) -- It actually could be a _general_ (clam, ladspa) reload
>>> option if it is easier.
>>>       

For ladspa plugins is really simple, is basically the same code used for 
the faust ones. But I have to check how are working the others plugins 
constructors, and I don't have Windows to check how the libraries 
management works on it. So, for the release I'm a little afraid to do 
that...

>> Maybe, the fist goal should be obtaining (and keeping) a list of the loaded 
>> plugin libraries (and maybe a list the processings they contain) so that we 
>> can provide a unload/reload dialog with the list.
>>     
>
> Why not just "reload" and avoid putting duplicate keys in the factory --
> which AFAIK, is what is done for Faust?
>
> Much more simpler first goal, I'd say.
>   

I agree. Anyway, at least the first point of David suggestions would be 
needed:

El 08/04/2008 07:12 AM, David García Garzón escribió:
> My suggestion:
> * First move all dl_ calls to the base RunTimeLibraryLoader primitives (see 
> LoadLibraryError and FullyLoadLibrary) so that we can encapsulate the 
> platform dependant bits.
> * Add in the same class some static structure that holds the list of 
> libraries.
> * Add also a static state that holds the currently loading library and set it 
> and unset it when appropiate.
> * When registering a factory entry check that state and if set, populate the 
> structure or just add some metadata.
> * The factory registrator destructor should remove the processing type from 
> the factory (this should be TDD) in order to allow unloading the library.
>   

I was to ask about TDD, but google helped me: 
http://en.wikipedia.org/wiki/Test-driven_development :-)

I'm learning a lot of terms and concepts about software design lately. :)

> I am not sure whether this should work. But, anyway, be carefull, remember 
> that we are in release!!! The plugin system cannot be broken!
As I wrote above, I can test it only under Linux, so if you agree and 
the code works I could commit just for the non-windows environments for now.


Regards,
Natanael.

> P
>
>   
>> My suggestion:
>> * First move all dl_ calls to the base RunTimeLibraryLoader primitives (see 
>> LoadLibraryError and FullyLoadLibrary) so that we can encapsulate the 
>> platform dependant bits.
>> * Add in the same class some static structure that holds the list of 
>> libraries.
>> * Add also a static state that holds the currently loading library and set it 
>> and unset it when appropiate.
>> * When registering a factory entry check that state and if set, populate the 
>> structure or just add some metadata.
>> * The factory registrator destructor should remove the processing type from 
>> the factory (this should be TDD) in order to allow unloading the library.
>>
>> I am not sure whether this should work. But, anyway, be carefull, remember 
>> that we are in release!!! The plugin system cannot be broken!
>>
>> David.
>>
>>     
>
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>
>