On 17/11/2014 17:46, Schaufler, Casey wrote: [...] >>> TL;DR: preloading_preinitializing_daemon has been removed in Tizen 3 >>> because the replacement of WRT by Crosswalk made it quite useless. >> >> As I understood, WRT was the main use case for which >> preloading_preinitializing_daemon had been created. >> What about native applications? They also have a big number of libraries >> they are linked to. >> If preloading_preinitializing_daemon is removed, native application >> startup time will suffer. > > With WebApps the library set can be known in advance. This is > not the case for native Apps. You can't preload the libraries if > you don't know what they are. You don't want to preload libraries > you don't need, as that will increase the App's footprint. > Preloading libraries you don't need increases the opportunity > for security exploits as well.
We had a discussion on IRC with Ilya and it would make sense to try to find a low level solution to this problem, typically with ld-linux.so (in glibc). Some ideas to speed up natives startup time: * lazy loading libraries, as done in Solaris: https://docs.oracle.com/cd/E26502_01/html/E26507/chapter3-7.html - also see 'ld -z lazy', which seems not implemented (yet) in ld-linux.so. Some improvements were proposed by Samsung/Russia some time ago: https://sourceware.org/ml/libc-help/2013-02/msg00017.html * using prelink(8): prelink is built and available in Tizen, but not used. Anyone with other ideas ? PS: A fallback idea in am_session_agent: ---------------------------------------- If a low-level solution can't be found, we could still enable a library cache in the am_session_agent, as it was done before with the preloading_preinitializing_daemon. I'd suggest some improvements: - at startup, load a minimal bunch of libs from a small static list as it was done in the old daemon (may depend on the platform: load EFL libs for some platforms, load Qt5 libs for other ones...). At least we could consider most CAPI libs here. => Casey: no more libs than needed. Even better: less libs == less maintenance :) - each time we launch a new app, we list the required libs (like ldd does) and preload the missing ones => at some point a new native app will have all its libs cached... We could even have a LRU cache and take some lib out of the cache. I see one potential problem with this method: exec() is not used anymore to start a native app, but dlopen(<binary>)/dlsym("main")/run main() . IMO, this is less secure except if we're able to isolate the new process as exec() does, while keeping the benefits of the libs cache. I also see this idea as a hackish way of doing things that should be done at the system level. Thoughts ? Best regards -- Stéphane Desneux Intel OTC - Vannes/FR gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
