On 24/08/09 at 15:10 +0200, Petr Salinger wrote:
> >>>#913 test_thread.rb:219:in `<top (required)>':
> >>> open("zzz.rb", "w") do |f|
> >>> f.puts <<-END
> >>> begin
> >>> Thread.new { fork { GC.start } }.join
> >>> pid, status = Process.wait2
> >>> $result = status.success? ? :ok : :ng
> >>> rescue NotImplementedError
> >>> $result = :ok
> >>> end
> >>> END
> >>> end
> >>> require "zzz.rb"
> >>> $result
> >>>#=> "" (expected "ok")
>
> >>What the "fork { GC.start }" should do ?
> >
> >fork() the interpreter and run the garbage collector in the child. Not
> >sure why they do that.
>
> Is it the same fork as fork() in C-language/system call ?
Yes
> What is semantics of this in multithreaded environment ?
> Is it the same as C-one - i.e. child process is created with a
> single thread ?
Based on the following test code, the semantics are the same:
<---
require 'thread'
t = Thread::new do
sleep 60
end
t2 = Thread::new do
sleep 60
end
sleep 5
fork do
while true do
sleep 1
puts "child:"
p t
p t2
end
end
while true do
sleep 1
puts "parent:"
p t
p t2
end
sleep 5
-->
Outputs:
child:
#<Thread:0x00000001023960 dead>
#<Thread:0x000000010238b8 dead>
parent:
#<Thread:0x00000001023960 sleep>
#<Thread:0x000000010238b8 sleep>
>Finally, the main question is what it should test
> ???
I have no idea. But the test succeeds on other arches...
> >>>#916 test_thread.rb:254:in `<top (required)>':
> >>> STDERR.reopen(STDOUT)
> >>> exec "/"
> >>>#=> killed by signal 32
> >>>
> >>>Same: uh? What's signal 32 on FreeBSD?
> >>
> >>It is internal to threading library, similarly to linuxthreads.
> >
> >Arg. ruby tends to make assumptions about the thread library. If it
> >doesn't behave like NPTL, then some things might break. We had a similar
> >problem with hppa some time ago.
>
> What are the results of testsuite on hppa ? Does it fail similarly.
I don't know: the test suite is no longer run on hppa, since it caused kernel
crashes in the past.
> What should ' exec "/" ' even do ? Is it supposed to only fail ?
It's probably supposed to fail, but not crash the interpreter.
> This likely won't work in multithreaded environment. There is even
> not clean semantic of it. The succesfull exec should terminate all
> threads
> running old exec-file and start exactly 1 thread running new exec-file.
>
> Our current implementation works fine for normal "exec usage",
> i.e. fork + exec.
I could just exclude those two tests on FreeBSD, if that's fine for you...
--
| Lucas Nussbaum
| [email protected] http://www.lucas-nussbaum.net/ |
| jabber: [email protected] GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
