> -----Original Message----- > From: Stéphane Desneux [mailto:[email protected]] > Sent: Monday, November 17, 2014 10:15 AM > To: Schaufler, Casey; Ilya Palachev; [email protected] > Cc: Vyacheslav Barinov; Andrew Senkevich > Subject: Re: [Dev] Current status of preloading_preinitializing_daemon in > Tizen > > 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).
Before we go off solving the problem, do we have any numbers that indicate we even *have* a problem? > 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
