On the other hand, I see some problems with handling of fork()/exec().
There really should be reinitialization of locks in child,
the timer should be started using pthread_once(), the current
approach is fragile and might lead to start of more timer threads.
IMHO, the code needs audit in this area.
I.e., I really doubt the following code in process.c
for rb_f_fork(VALUE obj) is correct:
switch (pid = rb_fork(0, 0, 0, Qnil)) {
case 0:
#ifdef linux
after_exec();
#endif
rb_thread_atfork();
if (rb_block_given_p()) {
int status;
rb_protect(rb_yield, Qundef, &status);
ruby_stop(status);
}
Do this problem only affect the Linuxthread-based pthread
implementations, or also NPTL? I think that ruby is written with the
asumption that pthread == NPTL, unfortunately...
The bug is timing dependent, i.e. there is a race condition.
Sometimes the child process would have 2 timer threads, sometimes
it would have the expected 1.
Only the probability of 2 is higher on linuxthreads compared to NPTL,
but it can happen under any pthread implementation.
This particular case is guarded by "#ifdef linux", so we are not affected.
This kind of bug can be easily avoided by properly using the proper
POSIX pthread interface, in this case pthread_once()
http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_once.html
This would work correctly on both linuxthreads/NPTL and should on any
POSIX pthread conforming implementation.
Are there plans to switch to something that has
the exact NPTL semantics on FreeBSD ?
We plan to improve our conformance to POSIX pthread,
currently i.e. the getpid() is not the same in all threads.
My point is that also the ruby should try to work under
any POSIX pthread conforming implementation.
It i.e. should not use PTHREAD_CREATE_DETACHED and after that use pthread_join.
http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_join.html:
"The behavior is undefined if the value specified by the thread argument
to pthread_join() does not refer to a joinable thread."
It should use pthread_sigmask() instead of sigprocmask()
when available and so on.
http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_sigmask.html:
"The use of the sigprocmask() function is unspecified in a multi-threaded
process."
That is why I call for the code audit in this area.
Ideally, it would not require full conformance, but also
accept some known exceptions, like our getpid() difference.
As I already wrote, the hang in 1st test in
http://redmine.ruby-lang.org/issues/show/1525
also applies for us.
On the other hand, the ruby 1.9.x is mostly working for us.
Would be just possible to alert debian/rules somehow
to also kill the hanged tests ? Due to previously mentioned
timing issues,it might sometimes happen. It would be better
compared to completely disabled testsuite.
Petr
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
