work on dynamic libraries finished and ready for review

[Barry Smith]

On Oct 28, 2008, at 3:43 PM, Lisandro Dalcin wrote:

> On Tue, Oct 28, 2008 at 4:43 PM, Barry Smith <bsmith at mcs.anl.gov>  
> wrote:
>>  I'm curious why you didn't go all the way and make it a full
>> PETSc object (like I suggested). Did you have technical reasons
>> or was it mostly just fear of breaking something? I'm in the mood
>> to have it be "right" for our release coming up soon.
>>
>
> Just because I'm not still sure if the added complexity will really
> pay. I want to think a bit more about all this.

    Doing it the PETSc way may be slightly more complex, but it has the
advantage of following the PETSc paradigm exactly, while what we
have currently is just a hack paradigm. Note this is all my fault  
because
I was to lazy to implement it properly originally and just hacked it up.
>
>
> Whith the current implementation, I'm being able to dynamically load a
> Python shared library, dlsym() Python API calls to initialize Python,
> bootstrap petsc4py, and finally create Python-implemented
> matrix/ksp/pc/snes/ts objects inside let say a .py file in the working
> directory. So all my fixes seems so be enough for such rather
> 'complex' tasks.
>
> To be completelly clear: The only lacked feature is the ability of
> passing flags to dlopen(). And in the case of Windows, such flags do
> not make sense and they are ignored.
>
>
>> I agree, it should handle file:// in the standard manner (I think
>> it is the way it is because it was a simple hack to get file:  
>> working.
>>>
>
> OK, then 'file://' will be accepted, but a bare 'file:' will likely
> generate an error. Is this right? Or should I try to parse harder and
> accept any of 'file:', 'file:/', file://' ??

   Just handle the correct file://
>
>
>
>>> * When PetscFinalize() is called, now dynamic libraries are actually
>>> dlclose'd. But the dynlib list is traversed from the first entry to
>>> the last. Perhaps this could cause problems in some rare cases,  
>>> and we
>>> should do a reversed traversal.
>>
>> This sounds like it should be changed as you suggest.
>
> But then the library list should be a double-linked?. Or a O(N**2)
> go-to-end and remove-end whould be enough? IMHO, there is no point on
> optimizing this, right?

    Whatever, I would just do the simple thing.
>
>
>>  Feel free to push over after the changes you suggested above.
>
> OK, but please answer to the above questions.
>
>
> -- 
> Lisandro Dalcín
> ---------------
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
>