Re: [PATCH] Preload infrastructure.

[OndÅej BÃlka <neleai at seznam dot cz>]

On Tue, Oct 22, 2013 at 09:06:45PM +0000, Joseph S. Myers wrote:
> On Tue, 22 Oct 2013, Ondrej Bilka wrote:
> 
> > On Tue, Oct 22, 2013 at 02:56:08PM +0000, Joseph S. Myers wrote:
> > > On Mon, 21 Oct 2013, Ondrej Bilka wrote:
> > > 
> > on adding functionality only when it is perfect would cause harder
> > reviewing of incremental improvements as entire patch should be send,
> > making tracking of what is done harder.
> 
> Any public interface needs to be supported indefinitely.  We need to make 
> sure that public interfaces are well-designed before adding them.  (The 
> requirements for supporting a preloaded library are less strong than for 
> an exported shared library symbol, but still work on the presumption that 
> any interface added is fixed and permanent.)
> 


> > That is heuristic to detect quadratic behaviour. For you I will change
> > writes to atomic writes and it will work as it is, in multithreaded case
> > worst that could happen is that log message will be printed twice.
> 
> It should use thread-local storage, so the detection is independent in 
> each thread.
>
And also printed per thread instead of per-process which would defeat
suppressing duplicate message logic. 

> function usage should be named in a way that makes clear *what it aims to 
> do* rather than *how it is used*; likewise any wrapper shell script.  And 
> since there are two distinct uses here - checking for incorrect usage, and 
> suggesting optimizations - I think there should be two separate shared 
> objects and shell scripts (though it's certainly a good idea if it's 
> possible to use several of these shared objects together).
> 
That is bad idea as trying to preload more objects would cause
unnecessary code bloat, overriding part of library by other. This could
be solved by recursive wrappers which would also cause dependency if
user specified libA libB, libB libA and other issues.

Also for different use cases adding additional commands will confuse
user when issues could be solved by adding a switch.


> So: put this code in the debug/ directory like other debugging preloadable 
> libraries; split it up by the different things it's usable to debug, so 

Are you sure? I would add them to debug directory which would add many
files with different purposes which would make it harder to orient. You
have been warned.

> each installed shared object does one clearly defined thing and does it 
> well; model the build/install system on how other such libraries are 
> built/installed; model other things on those libraries as well (such as 
> using an environment variable to specify an output file, not a hardcoded 
> /tmp path); generally follow established coding practices for such 
> libraries.
>
Quick question, a -ldl and -lpthread are needed how do you add that?