Re: Introducing the nofork branch

[Julio Merino <jmmv84%gmail.com@localhost>]

On Fri, Mar 5, 2010 at 4:03 PM, Julio Merino <jmmv84%gmail.com@localhost> wrote:
> [...]
> I've been working on an experimental branch,
> org.NetBSD.atf.src.nofork, which basically gets rid of the forking and
> simplifies a lot of code.  Let me restate it: this is EXPERIMENTAL.
> Very experimental.  So far it is just a proof of concept, and the
> top-level TODO.nofork file will tell you, roughly, why.

Alright, just a heads up to say that this keeps moving forward!

The org.NetBSD.atf.src.nofork branch is back to a usable state.
However, there is still a fair amount of work to be done before it can
be considered "clean for release": other than some parts of the code
being Really Ugly (TM)[1], there are some regressions to be fixed[2].

However, given that this new code base looks promising (I have no
plans to go back), I'm tempted to merge the branch into the main
branch soon and deal with it.

So, basically, the new code base will supposedly make debugging of
failing tests easier.  But you know what, everything will be faster!
As a "proof", the time of "make installcheck" (which runs the
bootstrap tests and the atf test suite):

* Code in org.NetBSD.atf.src (the old code base):

real    2m24.422s
user    0m48.816s
sys     1m17.546s

* Code in org.NetBSD.atf.src.nofork (the new code base):

real    1m31.910s
user    0m29.814s
sys     0m52.301s

Sure, this is a very unscientific, non-relevant test.  But it
definitely makes a difference.  And, even better, there is still room
for improvement! I have some ideas that, I hope, should cut this time
down even further.

Anyway: again, comments welcome; enjoy! :-)

1: Code ugliness is subjective. I seriously think some pieces of the
code do not even deserve to exist in their current shape... but oh
well, they are ancient and they work, so I guess it's better to
release ugly stuff (specially if users are not even going to see it)
than to keep blocking a release forever in seek of perfection.

2: The most important one at the moment is to reimplement test case timeouts.

-- 
Julio Merino