On 7 November 2013 19:42, Thiago Macieira <thiago.macie...@intel.com> wrote:
> On quinta-feira, 7 de novembro de 2013 08:40:03, William Hallatt wrote: > > On 7 November 2013 00:38, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > > On quarta-feira, 6 de novembro de 2013 20:12:33, > phil.kursawe@gmail.comwrote: > > > > I see. I thought Qt renders using the system natively. It could load > > > > > > opengl > > > > > > > like it loads SSL support, dynamically. > > > > > > That's a solution we really dislike. > > > > Would you mind explaining why? My knowledge of this level of design is > > virtually non-existent so your input would be hugely appreciated (even if > > you can just provide me with a few related key words so that I may > research > > the concepts that influenced the design decision myself). > > Dynamic loading a library requires that we write the code to find the > library > to be loaded. That's extra code that we need to write, duplicating what the > dynamic loader already has. > > Unlike plugins, libraries can be anywhere in the system. Also, libraries on > Unix systems have version numbers attached to the file names and we have to > know *which* number to find. For example, for libudev, we need to scan for > both > libudev.so.0 and libudev.so.1. That means we, the developers, need to guess > what the system has. We can't indiscriminately load any number, since we > don't > know whether libudev.so.2 will retain compatibility. > > Dynamic loading also requires that we provide fallback code, if the > library we > request is missing. That's because dynamic loading does not write a > requirement into the library's header, which packaging tools know to look > for. > For the libudev case, we had to ensure that QtSerialPort has fallback in > case > it can't use udev to find the serial ports. For SSL support, we > transferred the > to the users: you *have* to check if QSslSocket::supportsSsl() returns true > before you start using SSL. > > Another drawback is that it generates worse code. Unless we start writing > assembly by hand, per platform, our finding and calling of functions in > loaded > libraries is not going to be as efficient as the one generated by the > compiler > and linker. We've done both solutions that search for all functions at > startup > (SSL), which in turn means we have a load-time impact searching for > functions > that may or may not ever be used; and we have solutions that do lazy > lookups > (D-Bus), but then the application has no graceful way to fail if a > function is > missing at runtime: it can only crash. > > There's also an issue of thread-safety: libraries properly linked to get > loaded and initialised before the application reaches main(), which means > no > threads are running. Libraries dynamically loaded may be loaded into the > application while multiple threads are running. Some libraries may not like > being accessed from multiple threads. > > And then there's the question of when to unload them. We have to figure out > when to unload those libraries by ourselves. I did a lot of work to rewrite > the QLibrary static unloader in Qt 5.2 and, trust me, it was not easy. > Moreover, we may end up unloading a library from QtCore's global > destructors > before another global destructor gets run, one that still requires the > library. Our best bet would be to actually leak the loaded libraries. > > Finally, on platforms that make use of prelinking, libraries only loaded > through dynamic loading will, at best, not be prelinked. At worst, it will > actually have been prelinked to the wrong address and cause a > pessimisation. > > So, in all, I will oppose any use of dynamic loading of libraries. I will > accept only when we're forced to, like udev and OpenSSL. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > > Hi Thiago, Thank you very much for taking the time out to write that up. I appreciate it immensely! Have a great weekend, William.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest