On Wed, Nov 23, 2011 at 9:24 AM, Stephan Bergmann <sberg...@redhat.com> wrote: >>> Second, static data is a problem, as is initialize-once data in a >>> multi-threaded world. >> >> humm ?? initialize _before_ getting to the multithreaded part. > > which a *library* like sal cannot do
who said that sal has to auto-initialized the service. main() explicitly call sal_init_trace_services(char* log_env_descrition) (or whatever) and store the resulting array of logging context in a globally visible variable that the tracing macro can use. > >> I'm not arguing against the format of the configuration, but against >> the delayed-parsing repeated for each and every log message. >> (which is pointless since you use an env-variable so it is an >> execution-invariant -- unless you are thinking about adding a >> uno-service to change it on the fly ;-) ) > > Honestly, I am not worried about the performance of the current > implementation at all. If it should ever become a bottleneck (esp. if we > ever decide to enable logs in production builds), we could rather easily > improve it (though by adding complexity), without (that's my hope having > designed it that way) having to modify the interface. If you use a string as a trace-selector you will never get something with performance good-enough for release code. you need a numeric level and a numeric module/feature selector. You need a system so that when the trace are not wanted a trace-point cost a couple of integer testing at worse. you can't take a call, you cant' have to construct arguments for the call, you certainly can't have c++ object instantiation/clone/copy etc... Norbert _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice