Henri Verbeet hverbeet@codeweavers.com writes:
diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c index 36f1499..0d383bd 100644 --- a/dlls/ntdll/thread.c +++ b/dlls/ntdll/thread.c @@ -384,6 +384,7 @@ static void start_thread( struct startup_info *info ) thread_data->pthread_id = pthread_self();
signal_init_thread( teb );
- signal_init_thread_fpu(); server_init_thread( func ); pthread_sigmask( SIG_UNBLOCK, &server_block_set, NULL );
This should be done inside signal_init_thread(), that's already meant for platform-specific setup, there's no need to add a separate entry point. Also you may want to do an fninit if new threads are not supposed to inherit FPU state.
On 16 June 2010 19:36, Alexandre Julliard julliard@winehq.org wrote:
This should be done inside signal_init_thread(), that's already meant for platform-specific setup, there's no need to add a separate entry point.
That was the original plan, but signal_init_thread() is also called by thread_init().
Henri Verbeet hverbeet@gmail.com writes:
On 16 June 2010 19:36, Alexandre Julliard julliard@winehq.org wrote:
This should be done inside signal_init_thread(), that's already meant for platform-specific setup, there's no need to add a separate entry point.
That was the original plan, but signal_init_thread() is also called by thread_init().
You have to handle that anyway. If you add a generic init_thread_fpu() entry point it has to be called for all threads too, otherwise it's not really generic. The initial thread can be detected for instance by checking if the process heap exists.
-
Alexandre Julliard -
Henri Verbeet