Thanks Zaxo, castaway and liz for replying. After more investigation, now I clearly believe that it is detach() now broken. The version I used is Win32, but the bug could well be across all platforms. Although as liz pointed out, the threading implementation is platform specific, I believe, most likely what broken is the common wrapper on top of the threading.
Theoritically, there was no need for detach() in my code. I added them against my own will, as it was a must under 5.8.1 thread. Under 5.8.1, there was a huge memory leak without detach(), making it even worse, Perl didn't check null pointer returned from malloc, and after a while, once the memory leak is big enough, and the program can no longer allocate memory, the script just crashes.
I tried to remove those detach(), and ran my script again, it seems fine, and no longer crashes like 5.8.1. But as I pointed out, now detach() core dumps.
This is really a warning sign, and I am really concerned about the quality of, not just a particular release, but their development and verification process. To be frank, it is a big surprise to see that, they didn't carefully test some basic cases in the area, which they applied some big fixes.
I am not worried about couple of bugs, but I can become really concerned if there are evidences showing that the way they control the quality of releases is flawed, and their verification (testing) process is flawed.
We cannot control the quality of other people's work, but at least I can report the problem, and help them a little bit.
| [reply] |
So you had to remove a workaround for a no longer existent bug from your code. Sounds like an overall win to me. I don't see how you can talk about poor QA when the p5p folks explicitly mention that they're aware that the new code is problematic. Apparently they simply deemed the old code so bad that they preferred to toss out unfinished code for this fix-date release than keep the previous stuff.
At least judging by the amount of investigation to prepare your initial post (none, you just complained "my scripts are broken now" - if you made any debugging attempt you certainly didn't mention it) I'd be more inclined to trust the p5p opinion.
Update: I wasn't saying detach were a workaround per se, just that pg put it in "against his will" as he says because it was necessary.
Makeshifts last the longest.
| [reply] |
There is no doubt that, to break detach() is absolutely a bug. When it is true that it was a workaround to use detach() in my original code, please remember that it is absolutely valid to detach a thread. I can choose to keep the detach(), and there is nothing wrong with that.
Now to those people who wish to detach() their threads, they have to implement a workaround without detach(), and then put detach() back when it is fixed. Is this a "overall win" to us?
"I don't see how you can talk about poor QA when the p5p folks explicitly mention that they're aware that the new code is problematic."
If they explicitly mentioned that they knew detach() is broken, I would probably say nothing about their QA, but that is simply not the case. After all, it is not me talking about the poor QA, but detach().
"...this fix-date release..."
What makes the "fixed date" more important than the quality of the release?
| [reply] |
