This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> There is a race condition in linuxthreads during thread creation on > architectures that use a dedicated thread register. Between the point the > thread is created and inserted in the list of active threads, and the > point the thread register is initialized in the child a cancel signal may > arrive, with the thread manager calling pthread_handle_exit. ... > To fix this race I have blocked the cancel signal in the manager around > the clone call, so that the child does not call the signal handler before > thread_self is initialized. Wouldn't it be enough to check for this special case in pthread_handle_sigcancel(), like so: static void pthread_handle_sigcancel(int sig) { pthread_descr self = thread_self(); sigjmp_buf * jmpbuf; if (self == &__pthread_manager_thread) { if (thread_self_stack() == &__pthread_manager_thread) { __pthread_manager_sighandler(sig); return; } /* Oops, thread_self() isn't working yet.. */ self = thread_self_stack(); } ... with thread_self_stack() being the current 'normal' thread_self(). I'd rather see cancellation becoming a little slower than every pthread_create() requiring two more system calls. Regards, Wolfram.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |