OpenE2K/gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

mf-hooks3.c (main_seen_p): Remove.

Browse Source 
* mf-hooks3.c (main_seen_p): Remove.
	(__mf_get_state): Remove attempt to recognize the main thread.

From-SVN: r103119
This commit is contained in:
Ulrich Weigand 2005-08-15 20:26:46 +00:00 committed by Ulrich Weigand
parent b5568f074b
commit be53afcf39
2 changed files with 9 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
libmudflap/ChangeLog
View File

@ -1,3 +1,8 @@
2005-08-15 Ulrich Weigand <weigand@informatik.uni-erlangen.de>
* mf-hooks3.c (main_seen_p): Remove.
(__mf_get_state): Remove attempt to recognize the main thread.
2005-08-15 Maciej W. Rozycki <macro@linux-mips.org>
* configure.ac: Test for the name of the symbol used for the entry

23
libmudflap/mf-hooks3.c
View File

@ -104,11 +104,6 @@ struct mf_thread_data
static struct mf_thread_data mf_thread_data[LIBMUDFLAPTH_THREADS_MAX];
static pthread_mutex_t mf_thread_data_lock = PTHREAD_MUTEX_INITIALIZER;
/* Try to identify the main thread when filling in mf_thread_data. We
should always be called at least once from the main thread before
any new threads are spawned. */
static int main_seen_p;
#define PTHREAD_HASH(p) ((unsigned long) (p) % LIBMUDFLAPTH_THREADS_MAX)
static struct mf_thread_data *
@ -176,11 +171,9 @@ __mf_get_state (void)
if (data)
return data->state;
/* The main thread needs to default to active state, so that the global
constructors are processed in the active state. Child threads should
be considered to be in the reentrant state, so that we don't wind up
doing Screwy Things inside the thread library; it'll get reset to
active state in __mf_pthread_spawner before user code is invoked.
/* If we've never seen this thread before, consider it to be in the
reentrant state. The state gets reset to active for the main thread
in __mf_init, and for child threads in __mf_pthread_spawner.
The trickiest bit here is that the LinuxThreads pthread_manager thread
should *always* be considered to be reentrant, so that none of our
@ -189,15 +182,7 @@ __mf_get_state (void)
stuff isn't initialized, leading to SEGV very quickly. Even calling
pthread_self is a bit suspect, but it happens to work. */
if (main_seen_p)
return reentrant;
else
{
main_seen_p = 1;
data = __mf_find_threadinfo (1);
data->state = active;
return active;
}
return reentrant;
}
void