apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: [PATCH] apr_dso_load2() with flags support
Date Wed, 21 Sep 2005 14:18:20 GMT
On Wed, Sep 21, 2005 at 09:03:54AM -0500, William Rowe wrote:
> Ping since the thread tied here, and Joe's looking for an answer...

Eh?  Everything you say below is reasonable.  But that doesn't help me 
understand why you say the proposed API is "unportable" nor to resolve 
your veto.  What question do you need anybody else to answer?

Again: can you propose an alternative apr_dso_open_ex() API so I can 
understand your point?

> William A. Rowe, Jr. wrote:
> >Joe Orton wrote:
> >
> >>
> >>What's the default behaviour of the current API across all platforms?  
> >>I have no idea, I expect it differs wildly from AIX to Windows and 
> >>back.  What exactly do you propose?
> >
> >
> >AIUI (and I don't necessarily agree with these choices, but we are stuck 
> >;-)
> >
> >* Load Global.  Every platform I'm aware of will map into the symbol
> >  table.  Now on Win32, OS2, and OS/X (using two-level namespace) these
> >  symbols will be by-dso.  E.g. these three examples actually have
> >  multiple symbols of the same name, distinguished by the library's name.
> >
> >  - disabling 'load global' is very effective for loading modules in
> >    parallel.  Name clashes in Linux cause dlopen to barf.  Name clashes
> >    on HP/UX produce 'arbitrary' results.  Better to explicitly load
> >    most libraries local, and then query the entry points, data or code,
> >    as needed.
> >
> >* Bind Now, as we Run Constructors and Library Entry Points
> >
> >  - disabling 'bind now' is actually a misnomer, what we are really
> >    saying with bind deferred, IIUC, is that we plan to only grab
> >    some static data or structures, and then dump the DSO without
> >    it ever actually performing code operations.
> >
> >I think the bind now should be more abstract, to accomplish a specific
> >purpose.  If they choose LAZY, are the dependent libraries and symbols
> >resolved when the library calls them?  Consistant across platforms?
> >Would, say, LAZY on Linux allow the library to perform just-in-time sym
> >resolution, while LAZY on AIX might cause the library to crash when
> >trying to call an unresolved function?
> >
> >As long as the goal is to produce the fewest surprises for APR users
> >(developers) I'll be happy with the outcome :)

View raw message