Merged revisions 301594 via svnmerge from

https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
  r301594 | mnicholson | 2011-01-12 12:50:31 -0600 (Wed, 12 Jan 2011) | 15 lines
  
  Removed a usleep(1) that shouldn't be necessary in session_do, and removed the
  ms_t member from the mansession_session structure.
  
  Merged revisions 301591 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r301591 | mnicholson | 2011-01-12 12:39:03 -0600 (Wed, 12 Jan 2011) | 5 lines
    
    Don't store the thread id for the manager session in the structure we pass to
    the thread for the manager session.
    
    ABE-2543
  ........
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@301595 65c4cc65-6c06-0410-ace0-fbb531ad65f3

main/manager.c

@@ -929,7 +929,6 @@ static const struct {
  * data.
  */
 struct mansession_session {
-	pthread_t ms_t;		/*!< Execution thread, basically useless */
 				/* XXX need to document which fields it is protecting */
 	struct sockaddr_in sin;	/*!< address we are connecting from */
 	FILE *f;		/*!< fdopen() on the underlying fd */
@@ -4687,19 +4686,6 @@ static void *session_do(void *data)
 		}
 	}
 
-	/* It is possible under certain circumstances for this session thread
-	   to complete its work and exit *before* the thread that created it
-	   has finished executing the ast_pthread_create_background() function.
-	   If this occurs, some versions of glibc appear to act in a buggy
-	   fashion and attempt to write data into memory that it thinks belongs
-	   to the thread but is in fact not owned by the thread (or may have
-	   been freed completely).
-
-	   Causing this thread to yield to other threads at least one time
-	   appears to work around this bug.
-	*/
-	usleep(1);
-
 	session_destroy(session);
 
 	ast_mutex_destroy(&s.lock);