@@ -152,6 +152,9 @@ class Command:
bb.event.fire(CommandExit(code), self.cooker.data)
else:
bb.event.fire(CommandCompleted(), self.cooker.data)
+ self.finishAsyncDisconnect()
+
+ def finishAsyncDisconnect(self):
self.currentAsyncCommand = None
self.cooker.finishcommand()
@@ -177,6 +177,7 @@ class ProcessServer():
self.command_channel = False
del self.event_writer
self.lastui = time.time()
+ self.cooker.command.finishAsyncDisconnect()
self.cooker.clientComplete()
self.haveui = False
ready = select.select(fds,[],[],0)[0]
There is a race where the client can have disconnected but the async command hasn't finished running and isn't cleared up by the idle handler. If a client connects and finds this state, it will fail as the server appears busy and no new async command can execute. The old idle handler code makes this unlikely but could explain some race issues. The new code with idle handling in a separate thread makes it much more likely. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> --- lib/bb/command.py | 3 +++ lib/bb/server/process.py | 1 + 2 files changed, 4 insertions(+)