bug-hurd
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]