Comments for Thiago Macieira's blog http://www.macieira.org/blog An Open Source hacker's ramblings Fri, 07 Dec 2012 21:42:41 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Comment on The strange world of (release) candidates by Thomas Pfeifferhttp://www.macieira.org/blog/2012/12/the-strange-world-of-release-candidates/#comment-533 Thomas Pfeiffer Fri, 07 Dec 2012 21:42:41 +0000 http://www.macieira.org/blog/?p=463#comment-533 Great to hear that you're doing release candidates the right way™ now :) Great to hear that you’re doing release candidates the right way™ now :)

]]> Comment on The strange world of (release) candidates by The strange world of (release) candidates - Bartle Doohttp://www.macieira.org/blog/2012/12/the-strange-world-of-release-candidates/#comment-531 The strange world of (release) candidates - Bartle Doo Fri, 07 Dec 2012 07:18:13 +0000 http://www.macieira.org/blog/?p=463#comment-531 [...] http://bugreports.qt-project.org.Let’s try and get the final out by the end of the year. Source: Planet KDE GD Star [...] [...] http://bugreports.qt-project.org.Let’s try and get the final out by the end of the year. Source: Planet KDE GD Star [...]

]]> Comment on Qt 5.0 beta 1 is out by Pau Garcia Quileshttp://www.macieira.org/blog/2012/08/qt-5-0-beta-1-is-out/#comment-524 Pau Garcia Quiles Sat, 01 Sep 2012 23:59:36 +0000 http://www.macieira.org/blog/?p=456#comment-524 @Thiago, Not prelinking is not really a problem for a database daemon, which is probably only restarted a few times a year tops. A desktop application is obviously different. @Thiago,

Not prelinking is not really a problem for a database daemon, which is probably only restarted a few times a year tops. A desktop application is obviously different.

]]> Comment on Qt 5.0 beta 1 is out by Thiago Macieirahttp://www.macieira.org/blog/2012/08/qt-5-0-beta-1-is-out/#comment-520 Thiago Macieira Fri, 31 Aug 2012 11:26:43 +0000 http://www.macieira.org/blog/?p=456#comment-520 @Pau: that works, but it has an overhead cost and it can't be prelinked. @Pau: that works, but it has an overhead cost and it can’t be prelinked.

]]> Comment on Qt 5.0 beta 1 is out by Thiago Macieirahttp://www.macieira.org/blog/2012/08/qt-5-0-beta-1-is-out/#comment-519 Thiago Macieira Fri, 31 Aug 2012 11:26:24 +0000 http://www.macieira.org/blog/?p=456#comment-519 @Digitalus: it's an option we're considering, but I'm not sure of the benefit. Distributions will build packages anyway, so why should we? I'd much rather that their packagers join us and publish their RPMs and DEBs and whatnot at the same time as the source code is released. @Digitalus: it’s an option we’re considering, but I’m not sure of the benefit. Distributions will build packages anyway, so why should we? I’d much rather that their packagers join us and publish their RPMs and DEBs and whatnot at the same time as the source code is released.

]]> Comment on Qt 5.0 beta 1 is out by Digitalushttp://www.macieira.org/blog/2012/08/qt-5-0-beta-1-is-out/#comment-517 Digitalus Fri, 31 Aug 2012 07:40:02 +0000 http://www.macieira.org/blog/?p=456#comment-517 What about using openSUSE Build Service for GNU/Linux binaries? It can compile packages for most major GNU/Linux distributions. What about using openSUSE Build Service for GNU/Linux binaries? It can compile packages for most major GNU/Linux distributions.

]]> Comment on Qt 5.0 beta 1 is out by Pau Garcia Quileshttp://www.macieira.org/blog/2012/08/qt-5-0-beta-1-is-out/#comment-516 Pau Garcia Quiles Thu, 30 Aug 2012 22:54:08 +0000 http://www.macieira.org/blog/?p=456#comment-516 <i> developers went to the “OpenSSL School of Releasing” (along with the Boost developers) and haven’t learned yet to make binary-compatible releases</i> A proprietary database we use solves this problem in an interesting way: They only depend (DT_NEEDED) on libc They dlopen all dependencies that you would normally link to They dlsym every function they depend on. I've been told they use some kind of autogenerated wrapper (which includes workaround implementations) but I have not reached the actual guys in charge of this part. This makes possible to develop applications which link to system libraries (for instance, libssl) and their libraries (which also link to libssl). It's quite a bit of work and it's certainly not something you want to do as an app developer, but for libraries on Linux, it looks like a neat solution. It's been working fine for them for quite some years already. developers went to the “OpenSSL School of Releasing” (along with the Boost developers) and haven’t learned yet to make binary-compatible releases

A proprietary database we use solves this problem in an interesting way:

They only depend (DT_NEEDED) on libc
They dlopen all dependencies that you would normally link to
They dlsym every function they depend on. I’ve been told they use some kind of autogenerated wrapper (which includes workaround implementations) but I have not reached the actual guys in charge of this part.

This makes possible to develop applications which link to system libraries (for instance, libssl) and their libraries (which also link to libssl).

It’s quite a bit of work and it’s certainly not something you want to do as an app developer, but for libraries on Linux, it looks like a neat solution. It’s been working fine for them for quite some years already.

]]> Comment on forkfd part 4: proposed solutions by Thiago Macieirahttp://www.macieira.org/blog/2012/07/forkfd-part-4-proposed-solutions/#comment-512 Thiago Macieira Mon, 30 Jul 2012 23:37:43 +0000 http://www.macieira.org/blog/?p=434#comment-512 You're more likely to run into a process limit than an fd limit. That functionality you propose is interesting, but doesn't solve my problem for QProcess. I need in QProcess to be woken up when <b>my</b> child process has died. If the code wakes up for other processes, it's just spurious CPU usage. What's more, remember that this must work simultaneously from multiple threads, in which case one fd might not be a good idea. You’re more likely to run into a process limit than an fd limit.

That functionality you propose is interesting, but doesn’t solve my problem for QProcess. I need in QProcess to be woken up when my child process has died. If the code wakes up for other processes, it’s just spurious CPU usage. What’s more, remember that this must work simultaneously from multiple threads, in which case one fd might not be a good idea.

]]> Comment on forkfd part 4: proposed solutions by Colin Waltershttp://www.macieira.org/blog/2012/07/forkfd-part-4-proposed-solutions/#comment-511 Colin Walters Mon, 30 Jul 2012 14:12:37 +0000 http://www.macieira.org/blog/?p=434#comment-511 One fd per child process is kind of unfortunate for some use cases; for example, I have a build program kind of like 'make' that may launch a lot of child processes, and it's actually pretty easy to run up against the 1024 limit. Why not make it like a bit more like signalfd, so you'd have forkfd_create()/forkfd_add_child(), and read() returns a structure that has data for a child? One fd per child process is kind of unfortunate for some use cases; for example, I have a build program kind of like ‘make’ that may launch a lot of child processes, and it’s actually pretty easy to run up against the 1024 limit.

Why not make it like a bit more like signalfd, so you’d have forkfd_create()/forkfd_add_child(), and read() returns a structure that has data for a child?

]]> Comment on forkfd part 2: Finding out that a child process exited on Unix by Thiago Macieirahttp://www.macieira.org/blog/2012/07/forkfd-part-2-finding-out-that-a-child-process-exited-on-unix/#comment-508 Thiago Macieira Fri, 27 Jul 2012 23:19:30 +0000 http://www.macieira.org/blog/?p=416#comment-508 @Olivier: Either way, it's still not thread-safe. We could have that sig_atomic_t extra to indicate whether the old handler is set, but it's not thread-safe. The other option is worse because another thread could install another handler in-between and we'd lose it. By the way, sig_atomic_t is enough for atomicity with signals, but not with multithreading. For that, you need C11 or C++11 and a real atomic, with a store-release operation. My code uses the proper semantics. @Olivier: Either way, it’s still not thread-safe. We could have that sig_atomic_t extra to indicate whether the old handler is set, but it’s not thread-safe. The other option is worse because another thread could install another handler in-between and we’d lose it.

By the way, sig_atomic_t is enough for atomicity with signals, but not with multithreading. For that, you need C11 or C++11 and a real atomic, with a store-release operation. My code uses the proper semantics.

]]>