Comment 8 for bug 520715

It appears I was incorrect about Red Hat. However, the default ruby build does not include pthreads, which had me confused for quite some time why the debian package was failing while when I built ruby by hand it worked fine.

Here's what I know:

Reasons to consider disabling pthreads:
- As you say, there are performance impacts of enabling pthreads, particularly with puppet.
- Pthreads causes breakage to puppet under unknown circumstances, but repeatable in certain varied environments.
- Puppet is an important part of ubuntu's plan for cloud management.

Reasons to not disable pthreads:
- It breaks libtcltk-ruby1.8
- This will affect at most 0.03% (22 people) of the debian community according to the votes at:
http://qa.debian.org/popcon.php?package=ruby1.8 Ubuntu popcon data appears to be down at the moment.
- libtcltk-ruby has no packages that depend on it and provides no functionality of its own, thus nothing ubuntu provides makes any use of it.
- Everybody else uses pthreads, and it's what we've always done.
- Disabling pthreads might do something bad.

In summary, pthreads causes significant problems in a well known and important package to the ubuntu community. Disabling it breaks something that is almost completely unused. Otherwise it MAY break something else and we're scared to try it because no one else is doing it. The fact that it's how it's been done for a few years is not in my mind a valid reason to continue doing it when the original reason it was implemented is not clear.

The reasons to disable it are known and significant. The reasons to leave it are unknown or irrational. I think it's time to evaluate priorities.

Here is what I don't know:
- Anything about ruby. I just know I need to get puppet working in our environment, and this was blocking my progress. I found a solution by analyzing things that changed from version to version, and tracked down where the problem began. I don't know how to test ruby libraries or even what any of them do. I would expect that Ubuntu would have a suite of tests to verify that any package changes don't cause regressions. If such tests existed, I think they could verify that functionality without pthreads was still acceptable.

Sure it would be nice if ruby worked with pthreads, and without any performance impact. I've filed the bug, but there's been no response. Even if they look at it, I'm not sure how likely it is to propagate into Lucid before release. Being an LTS release, and the likelihood of enterprises focusing on it, I would think that having a properly working puppet upon release would be a priority, and I have yet to see any tangible benefit that having pthreads enabled gives us.

I do not have a reproducible test case I can make public yet, and even so, it appears to depend on hardware. Some machines do not exhibit the error. Running puppet under strace makes the problem go away. The two together imply that it is very timing dependent. I will continue trying to find a simple way to reproduce the bug.