Index: audUnix.cpp
===================================================================
RCS file: /cvsroot/audio/device/platform/unix/audUnix.cpp,v
retrieving revision 1.12.2.3
diff -u -r1.12.2.3 audUnix.cpp
--- audUnix.cpp 16 Jul 2008 13:37:00 -0000 1.12.2.3
+++ audUnix.cpp 17 Mar 2009 12:37:48 -0000
@@ -381,7 +381,16 @@
{
HXLOGL4 (HXLOG_ADEV, "CAudioUnixOUT::_Imp_Close signaling
event...");
m_pAvailableDataEvent->SignalEvent();
+#ifdef _XANDROS
+ //XXXdeepakj: Not calling Exit() in case of Xandros ARM as it was
resulting
+ //in HANG at pthread_join(). This can be a issue with the pthread library.
+ //'join' will just wait for the child thread to exit. If we don't wait, the OS
+ //will clean up the thread anyway. It will not result in any leaks or
+ //performance problems
+ //m_audioThread->Exit(0);
+#else
m_audioThread->Exit(0);
+#endif //#ifdef _XANDROS
}
#endif
I know that you have a deadline tomorrow, so this is OK for your
branch only. As has been mentioned there are going to be better
fixes, that will take some time to get to. The one problem with
that above, as Daniel pointed out, is that the current pthreads
libs will leak their stack (possibly). It will be cleaned up
when the mail thread exits. The default min for a thread stack
is 16K last time I looked. It can be more, as each thread inherits
its stack size form its parent thread. So we are talking about >~16K
for each time the audio thread is created. If the app is restarted all
of that will be reclaimed. However, try this to not leak that 16K:
If you have time, try changing:
+ //m_audioThread->Exit(0);
to some call down into pthreadthreads.cpp that does:
pthread_detach(child_thread_id);
like:
m_audioThread->Detach(...); //detach the child thread.
you will want to do that before m_pAvailableDataEvent->SignalEvent()
rather the after like we do for a join(). We never use the return
status from that thread, so it doesn't really matter if we join
or detach it.
that is a fast fix that can stop any leaks. Keep it wrapped
in your #defines though as it has not been tested before on
any of our other un*xs.
More later.
--greg.
_______________________________________________
Audio-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/audio-dev
