On 31/08/09 at 11:32 +0200, Petr Salinger wrote:
> >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.
Hi Petr,
I don't really feel qualified to report a bug on this myself. Would you
take care of that? The official bug tracker is
http://redmine.ruby-lang.org/.
> 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.
Well, we could try to disable only the tests that are prone to hang.
--
| 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]
