This patch speeds up process initialization on 64-bit systems. Maybe
the comment "Initialize signal processing here ..." should be re-worded
or removed completely.
The speed difference can be noticeable.
"while (true); do date; done | uniq -c" manages more than 3 times more
"date" executions per second on my system.
2010-09-01 Magnus Holmgren <magnus...@gmail.com>
* dcrt0.cc (dll_crt0_0): Remove call to sigproc_init. It creates
a thread, and execution of that thread can be delayed during
DLL init, slowing things down (seen on 64-bit systems).
(dll_crt0_1): Always call sigproc_init.
Index: src/winsup/cygwin/dcrt0.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/dcrt0.cc,v
retrieving revision 1.382
diff -u -p -r1.382 dcrt0.cc
--- src/winsup/cygwin/dcrt0.cc 30 Aug 2010 23:23:28 -0000 1.382
+++ src/winsup/cygwin/dcrt0.cc 1 Sep 2010 17:49:26 -0000
@@ -740,11 +740,9 @@ dll_crt0_0 ()
}
}
- /* Initialize signal processing here, early, in the hopes that the creation
- of a thread early in the process will cause more predictability in memory
- layout for the main thread. */
- if (!dynamically_loaded)
- sigproc_init ();
+ /* Don't initialize signal processing here. It creates a thread, and
+ execution of threads created during DLL initialization can be
+ delayed (e.g., on 64-bit Windows Vista and Windows 7) */
user_data->threadinterface->Init ();
@@ -789,8 +787,10 @@ dll_crt0_1 (void *)
{
extern void initial_setlocale ();
- if (dynamically_loaded)
- sigproc_init ();
+ /* Initialize signal processing here, early, in the hopes that the creation
+ of a thread early in the process will cause more predictability in memory
+ layout for the main thread. */
+ sigproc_init ();
check_sanity_and_sync (user_data);
/* Initialize malloc and then call user_shared_initialize since it relies
--
Magnus
