[bitbake-devel] [PATCH] server/process.py: Change timeout error handling

[Richard Purdie]

On Wed, 2012-11-21 at 09:31 -0700, Chris Larson wrote:
> On Wed, Nov 21, 2012 at 2:21 AM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
>         In normal usage, we never hit the timeout issue. If we do, it
>         becomes obvious
>         that the current error handling is not good enough. The
>         request may have made it
>         to the server and the answer will get queued. This means the
>         next command may get
>         the return value from the previous command with suitably
>         puzzling results.
>         
>         Without rewriting large sections of code, its not possible to
>         avoid this problem.
>         It is better to increase the timeout to several seconds giving
>         the server a chance
>         to respond and if it does timeout, hard exit since recovery is
>         not possible with the
>         code base today.
>         
>         I'd be happy to see the structure of this code improved but
>         this quick fix at least
>         stops corrupted builds from happening which has to be a good
>         thing.

>         Signed-off-by: Richard Purdie
>         <richard.purdie at linuxfoundation.org>
> 
> 
> This code is run in UI context, not server context, no? So the UI
> should be checking the return of runCommand, seeing the error, and
> aborting itself in whatever clean fashion is appropriate, rather than
> the rather less so immediate sys.exit. Given that, I don't really see
> how switching to bb.fatal here is buying us much. If we truly want
> that error path to be different from that of other command failures,
> then I would think that raising an appropriate exception (e.g.
> something other than SystemExit) would be better.

The issue is that after this particular failure, any further runCommand
is going to go badly wrong. "Timeout" would imply you could retry and in
this case as described above, you cannot (which I agree sucks).

So I think exiting in this case isn't such a bad thing although I'm less
than happy about it. The only thing the UI could do is throw an error
and exit.

Cheers,

Richard