#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 ?
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 ? Finally, the main question is what it should test ???
#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.
What should ' exec "/" ' even do ? Is it supposed to only fail ?
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.
Petr
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
