Hi,
On Tue, Mar 22, 2011 at 8:11 PM, Vitaly Wool <vitalywool@xxxxxxxxx> wrote:
> Greetings,
>
> I'd got a nasty hang in my Android phone when I turned bluetooth off
> from the UI while the music was playing over bluetooth connection.
as a follow-up on this, it looks like the problem is fairly generic on
one hand but may be specific to Android, on the other.
bluetoothd defines its own signal handler for SIGTERM (sig_term())
which calls g_main_loop_quit(event_loop).
The latter will call g_main_context_wakeup_unlocked() which is exactly
the following:
g_main_context_wakeup_unlocked (GMainContext *context)
{
#ifdef G_THREADS_ENABLED
if (g_thread_supported() && context->poll_waiting)
{
context->poll_waiting = FALSE;
#ifndef G_OS_WIN32
write (context->wake_up_pipe[1], "A", 1);
#else
ReleaseSemaphore (context->wake_up_semaphore, 1, NULL);
#endif
}
#endif
This is meant to make bluetoothd quit waiting on a poll() call in
g_main_context_poll() which is polling on the read descriptor of this
pipe along with all the other descriptors supplied by bluetoothd.
Unfortunately gthreads are not initialized in Android, moreover, this
part of glib code is not even compiled, so g_thread_supported()
returns false and this function is basically no-op in the Android
case.
So if there are no other events for the poll() to quit, we'll get
stuck in poll() forever because the write to wake_up_pipe will never
happen.
Still don't have a good enough idea on how to fix it in the right way though...
~Vitaly
--
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
