Fw: [ruby-core:39153] Re: [Ruby 1.9 - Bug #5239][Assigned] bootstraptest/runner.rb: assert_normal_exit logic broken on Debian/GNU kFreeBSD
Hi,
See below a message from Motohiro KOSAKI, a Ruby developer (Cced).
Full discussion at http://redmine.ruby-lang.org/issues/5239
Short story:
Some breaks in the Ruby test suite on kfreebsd. The code does:
- create a process with fork()
- create a (p)thread
- issue a waitpid() from the pthread on the process
so, the waitpid() is issued from the parent process, but not the parent
thread. Linux accepts that, kfreebsd fails, Motohiro says that FreeBSD works.
I don't understand the differences between FreeBSD and kfreebsd regarding
pthreads. Is it documented somewhere?
Can you fix this? It's not blocking for me: Motohiro accepted to
apply a fix. But this behaviour might cause other bugs.
- Lucas
----- Forwarded message from KOSAKI Motohiro <kosaki.motohiro@gmail.com> -----
From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: ruby-core@ruby-lang.org
Date: Sun, 28 Aug 2011 09:42:01 +0900
Subject: [ruby-core:39153] Re: [Ruby 1.9 - Bug #5239][Assigned] bootstraptest/runner.rb: assert_normal_exit logic broken on Debian/GNU kFreeBSD
Reply-To: ruby-core@ruby-lang.org
List-Id: ruby-core.ruby-lang.org
>> > RATIONALE
>> > A call to the wait() or waitpid() function only returns status on an immediate child process of the *calling process*
>>
>> The pthread rule is, pthread_create() doen't introduce any process tree change. In the other words, kFreeBSD is buggy.
>
> One could argue that a different PID makes a different process, but it's
> correct that it's not a different process.
popen makes different process. and Thread.new don't make a process. isn't it?
Therefore a subthread clealy can use waitpid() for waiting child
process. Moreover
real FreeBSD works this test completely. It's only kFreeBSD issue.
I wonder why kFreeBSD don't handle threading correctly. Long time ago,
linuxthreads made the same mistake and application users sufferd from it.
I didn't expected we observed the same issue at 21th century.
----- End forwarded message -----
Reply to: