apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan <...@wikifamilies.info>
Subject Re: [PATCH] apr_dso_open()
Date Fri, 06 Jan 2006 20:05:36 GMT
Joe Orton wrote:

>On Fri, Jan 06, 2006 at 08:04:53AM -0800, Jonathan wrote:
>  
>
>>Comments?
>>
>>This adds apr_dso_open(). Its intention is to only open a dynamic shared 
>>library and to do so without any further process to automatically bind 
>>global symbols, unlike apr_dso_load().
>>    
>>
>
>Splitting the differrent implementations into separate files should be 
>done separately to adding any new interfaces; if you wanted to submit a 
>patch for that it's probably be a good idea.
>  
>
That can be done.

>For the new interface: offering GLOBAL|NOW and LAZY|LOCAL as the only 
>two options is just odd; the most common uses I'd see would be 
>GLOBAL|NOW and LOCAL|NOW, LAZY is useful only in rare cases.
>  
>
RTLD_NOW is useful for DLLs that expect to export symbols and to debug 
code. It does not work well for DLLs that are set-up to import symbols 
and that take advantage of private/local DLL namespace, especially when 
mixed with code that expects exported symbols. RTLD_LAZY is not 
uncommon. It is, perhaps, less used because it requires a bit more work 
to code properly. Some systems do the equivalent of RTLD_LAZY, by 
default, and require a explicit flag or such to bind everything 
immediately. With RTLD_LAZY, it is possible to not export any symbols 
and not cause any bind and still access the code in a library through 
dlsym(), yet, with RTLD_NOW, it can be done automatically or automated 
with compiler options. That automatic bind is not always desirable.

LOCAL|NOW and GLOBAL|NOW only changes symbol depth. GLOBAL|NOW and 
LOCAL|LAZY allows symbol breadth and namespace breadth. I suggest 
another function, apr_dso_open_ex(), if we want more OS specific 
options. LOCAL|LAZY, however, is portable in likeness across other 
supported systems without dlopen().

>I think any new function should just use flags to allow the user to 
>choose any of the four combinations where possible. (I don't understand 
>the vetoes on previous patches which did that, so I can't offer any 
>advice on how to do this without still incurring a veto; try it and see 
>I guess)
>
>Regards,
>
>joe
>
>
>  
>
Not all systems have only four options and the same likeness in options. 
We can, however, limit it to two functions, for now, instead of just the 
only one that we have.

Best,

Jonathan

Mime
View raw message