[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Fw: [ruby-core:39153] Re: [Ruby 1.9 - Bug #5239][Assigned] bootstraptest/runner.rb: assert_normal_exit logic broken on Debian/GNU kFreeBSD


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

>> > 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: