Hi Andrzej, On Sun, Feb 2, 2014 at 7:16 AM, Andrzej Kaczmarek <andrzej.kaczmarek@xxxxxxxxx> wrote: > This patch adds wrappers for BT HAL callback which execute them in main > thread instead of notification_handler() thread. Otherwise test > execution is prone to race conditions since we do not provide any > locking mechanism for tester. In my opinion, this is becoming too messy. I'm getting races even inside the emulator code: sometimes bthost->ncmd becomes zero before a HCI command is sent by the emulated host because the Command Status / Command Complete comes after the command is written to the socket, but before bthost->ncmd is decremented. Also try running android-tester under valgrind. At least for me, I get a few failures that I don't have when running without valgrind (at least one in HIDHost apparently due to if_bluetooth->enable() not being called on test setup and thus the tests rely on finishing before the controller is powered off by the kernel after initialization). IMHO, the best approach would be to keep all HAL API usage in a separate process, and keep android-tester single-threaded. Of course, this could extra complexity for the required IPC between android-tester and this new process... Again, I'm not familiar with how HAL API works, all this is just based on my failed attempt to make android-tester run reliably under valgrind. Best Regards, -- Anderson Lizardo http://www.indt.org/?lang=en INdT - Manaus - Brazil -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
