[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hurd stacks, some more (was: RFC: ruby1.9.1 FTBFS)
From: |
Samuel Thibault |
Subject: |
Re: Hurd stacks, some more (was: RFC: ruby1.9.1 FTBFS) |
Date: |
Thu, 4 Jul 2013 18:24:06 +0200 |
User-agent: |
Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) |
Thomas Schwinge, le Thu 04 Jul 2013 17:06:09 +0200, a écrit :
> I'd rather have our mmap
> implementation in glibc do the proper thing when the MAP_STACK flag is
> set (the Ruby code does set it), and continue passing NULL for the
> request address.
Agreed completely.
> I wonder: if MAP_STACK is set, would it even be
> reasonable for mmap to ignore the supplied length, and instead use the
> one "proper" value, 0x200000?
We can round it up. Rounding it down would be more a concern.
> > Remaining one tries to kill -USR1 a process and expects it killed
> > after 1 sec. Patch increases wait time from 1 to 3, hurd is slow.
>
> > --- a/bootstraptest/test_fork.rb
> > +++ b/bootstraptest/test_fork.rb
> > @@ -30,7 +30,7 @@ End
> > assert_equal 'ok', %q{
> > begin
> > if pid1 = fork
> > - sleep 1
> > + sleep 3
> > Process.kill("USR1", pid1)
> > _, s = Process.wait2(pid1)
> > s.success? ? :ok : :ng
>
> Using the sleep function for synchronizing parallel processes is not
> exactly state of the art (but that is not your fault, of course) -- so
> yeah, if that does fix the issue, why not propose this patch.
I'm still surprised that we'd need more than 1s for killing a process.
Is there anything else running during the test? If so, sleeping is
indeed really a poor strategy.
Samuel