At Fri, 08 Feb 2008 17:01:50 +0100,
Paolo Bonzini wrote:
> 
> 
> > Paolo> Without the patch *and with any scheduler that executes same-priority
> > Paolo> processes fairly* the program is ensured to finish.  With the patch, the
> > Paolo> program might not finish.  The two producer processes might ping-pong control
> > Paolo> to each other, and the delay won't even be started.
> > 
> > A workaround that handles badly written beginner code but eventually
> > ruins the semantics for properly written expert code doesn't sound
> > very good.  It's like ensuring that every motorcycle sold automatically
> > comes with training wheels.  Ouch.
> 
> I wasn't saying that my code is practical or well written -- it's just 
> that I can prove it finishes.  But indeed your motorcycle metaphor is 
> what I was trying to say.

  If I'd use the analogy, what was suggested wasn't training wheels.
For casual, novice programmers, proposed change is basically
invisible.  Sure, you can write some bad code that may starve one
process but that may happen without the patch if you write code in
that way, though.

  The patch is useful when one trys to build a serious distributed
interactive system for example; in that case, the programmer should
know how to write good code so the system doesn't have to try to
provide "safety" as much.  One can always shoot his foot anyway.  But,
there, having real determinism would help so much to debug it and
achieve stable application.

-- Yoshiki