JehanneOS/newlib
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

* DevNotes: Add entry cgf-000023.

Browse Source 
* sigproc.cc (exit_thread): Remove now-unneeded sleep code.
This commit is contained in:
Christopher Faylor 2013-06-07 15:37:11 +00:00
parent 7eed26ae5b
commit 9791177448
3 changed files with 10 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
winsup/cygwin/ChangeLog
View File

@ -1,3 +1,8 @@
2013-06-07 Christopher Faylor <me.cygwin2013@cgf.cx>
* DevNotes: Add entry cgf-000023.
* sigproc.cc (exit_thread): Remove now-unneeded sleep code.
2013-06-05 Corinna Vinschen <corinna@vinschen.de>
* include/cygwin/version.h (CYGWIN_VERSION_DLL_MINOR): Bump to 21.

5
winsup/cygwin/DevNotes
View File

@ -1,3 +1,8 @@
2013-06-07 cgf-000023
Given the fact that the signal thread never exits there is no need
for exit_thread to ever block. So, nuke this code.
2013-01-31 cgf-000022
While researching the lftp behavior reported here:

15
winsup/cygwin/sigproc.cc
View File

@ -447,21 +447,6 @@ exit_thread (DWORD res)
# undef ExitThread
sigfillset (&_my_tls.sigmask); /* No signals wanted */
lock_process for_now; /* May block indefinitely when exiting. */
/* ES_EXIT_STARTING indicates that exit is in progress. After setting
exit_state to ES_EXIT_STARTING, the global dtors are running first,
then the exit state is set to the next level in do_exit. We must not
block the thread exit while the global dtors are running, because
one of them might have called pthread_join, which is perfectly valid
for a global C++ destructor.
FIXME: Do we need another state between ES_EXIT_STARTING and
ES_SIGNAL_EXIT to narrow the gap in which the thread exit
is still valid? */
if (exit_state > ES_EXIT_STARTING)
{
for_now.release ();
Sleep (INFINITE);
}
HANDLE h;
if (!DuplicateHandle (GetCurrentProcess (), GetCurrentThread (),
GetCurrentProcess (), &h,