Daniel Berger
2008-Feb-18 04:06 UTC
[Win32utils-devel] More on cross thread violation on Windows
Hi all,
Just investigating the source of errors for the test script at the
bottom of this email. Here''s the relevant code from eval.c:
#ifdef HAVE_NATIVETHREAD
if (!is_ruby_native_thread()) {
rb_bug("cross-thread violation on rb_thread_schedule()");
}
#endif
...
#ifdef HAVE_NATIVETHREAD
static rb_nativethread_t ruby_thid;
int is_ruby_native_thread() {
return NATIVETHREAD_EQUAL(ruby_thid, NATIVETHREAD_CURRENT());
}
And in ruby.h:
#elif defined(_WIN32) || defined(_WIN32_WCE)
typedef DWORD rb_nativethread_t;
# define NATIVETHREAD_CURRENT() GetCurrentThreadId()
# define NATIVETHREAD_EQUAL(t1,t2) ((t1) == (t2))
# define HAVE_NATIVETHREAD
#endif
So, somehow Ruby''s thread ID is no longer the same as what it
originally
started at? How can that be?
Regards,
Dan
# test.rb
require ''windows/console''
require ''windows/sound''
include Windows::Console
include Windows::Sound
CtrlHandler = Win32::API::Callback.new(''L'',
''I''){ |ctrl_type|
case ctrl_type
when CTRL_C_EVENT
puts "Ctrl-C event"
Beep(750, 300)
return true
when CTRL_CLOSE_EVENT
Beep(600, 200)
puts "Ctrl-Close event"
return true
when CTRL_BREAK_EVENT
Beep(900, 200)
puts "Ctrl-Break event"
return false
when CTRL_LOGOFF_EVENT
Beep(1000, 200)
puts "Ctrl-Logoff event"
return false
when CTRL_SHUTDOWN_EVENT
Beep(750, 500)
puts("Ctrl-Shutdown event")
return false
else
return false
end
}
if SetConsoleCtrlHandler(CtrlHandler, TRUE)
printf( "\nThe Control Handler is installed.\n" )
printf( "\n -- Now try pressing Ctrl+C or Ctrl+Break, or" )
printf( "\n try logging off or closing the console...\n" )
printf( "\n(...waiting in a loop for events...)\n\n" )
while true
end
else
printf( "\nERROR: Could not set control handler")
end
Wayne Vucenic
2008-Feb-18 07:36 UTC
[Win32utils-devel] More on cross thread violation on Windows
Hi Dan, "HandlerRoutine Callback Function: An application-defined function used with the SetConsoleCtrlHandler function. A console process uses this function to handle control signals received by the process. When the signal is received, the system creates a new thread in the process to execute the function." http://msdn2.microsoft.com/en-us/library/ms683242(VS.85).aspx Often Win32 creates a new thread to use to call a callback function. That seems to be what''s happening here. Best regards, Wayne On Feb 17, 2008 8:06 PM, Daniel Berger <djberg96 at gmail.com> wrote:> Hi all, > > Just investigating the source of errors for the test script at the > bottom of this email. Here''s the relevant code from eval.c: > > #ifdef HAVE_NATIVETHREAD > if (!is_ruby_native_thread()) { > rb_bug("cross-thread violation on rb_thread_schedule()"); > } > #endif > > ... > > #ifdef HAVE_NATIVETHREAD > static rb_nativethread_t ruby_thid; > > int is_ruby_native_thread() { > return NATIVETHREAD_EQUAL(ruby_thid, NATIVETHREAD_CURRENT()); > } > > And in ruby.h: > > #elif defined(_WIN32) || defined(_WIN32_WCE) > typedef DWORD rb_nativethread_t; > # define NATIVETHREAD_CURRENT() GetCurrentThreadId() > # define NATIVETHREAD_EQUAL(t1,t2) ((t1) == (t2)) > # define HAVE_NATIVETHREAD > #endif > > So, somehow Ruby''s thread ID is no longer the same as what it originally > started at? How can that be? > > Regards, > > Dan > > # test.rb > require ''windows/console'' > require ''windows/sound'' > include Windows::Console > include Windows::Sound > > CtrlHandler = Win32::API::Callback.new(''L'', ''I''){ |ctrl_type| > case ctrl_type > when CTRL_C_EVENT > puts "Ctrl-C event" > Beep(750, 300) > return true > when CTRL_CLOSE_EVENT > Beep(600, 200) > puts "Ctrl-Close event" > return true > when CTRL_BREAK_EVENT > Beep(900, 200) > puts "Ctrl-Break event" > return false > when CTRL_LOGOFF_EVENT > Beep(1000, 200) > puts "Ctrl-Logoff event" > return false > when CTRL_SHUTDOWN_EVENT > Beep(750, 500) > puts("Ctrl-Shutdown event") > return false > else > return false > end > } > > if SetConsoleCtrlHandler(CtrlHandler, TRUE) > printf( "\nThe Control Handler is installed.\n" ) > printf( "\n -- Now try pressing Ctrl+C or Ctrl+Break, or" ) > printf( "\n try logging off or closing the console...\n" ) > printf( "\n(...waiting in a loop for events...)\n\n" ) > > while true > end > else > printf( "\nERROR: Could not set control handler") > end > _______________________________________________ > win32utils-devel mailing list > win32utils-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/win32utils-devel >
Daniel Berger
2008-Feb-18 14:02 UTC
[Win32utils-devel] More on cross thread violation on Windows
Yeah, but why would that alter Ruby''s thread ID? I''m not saying you''re wrong, I''m saying I don''t get it. Also, I want to cleanup these warnings and see if it helps: eval.c eval.c(962) : warning C4018: ''>='' : signed/unsigned mismatch eval.c(4412) : warning C4646: function declared with __declspec(noreturn) has non-void return type eval.c(10708) : warning C4244: ''='' : conversion from ''double'' to ''long'', possible loss of data eval.c(10709) : warning C4244: ''='' : conversion from ''double'' to ''long'', possible loss of data eval.c(13200) : warning C4646: function declared with __declspec(noreturn) has non-void return type eval.c(13228) : warning C4645: function declared with __declspec(noreturn) has a return statement Thanks, Dan Wayne Vucenic wrote:> Hi Dan, > > "HandlerRoutine Callback Function: > An application-defined function used with the SetConsoleCtrlHandler > function. A console process uses this function to handle control > signals received by the process. When the signal is received, the > system creates a new thread in the process to execute the function." > http://msdn2.microsoft.com/en-us/library/ms683242(VS.85).aspx > > Often Win32 creates a new thread to use to call a callback function. > That seems to be what''s happening here. > > Best regards, > > Wayne > > On Feb 17, 2008 8:06 PM, Daniel Berger <djberg96 at gmail.com> wrote: >> Hi all, >> >> Just investigating the source of errors for the test script at the >> bottom of this email. Here''s the relevant code from eval.c: >> >> #ifdef HAVE_NATIVETHREAD >> if (!is_ruby_native_thread()) { >> rb_bug("cross-thread violation on rb_thread_schedule()"); >> } >> #endif >> >> ... >> >> #ifdef HAVE_NATIVETHREAD >> static rb_nativethread_t ruby_thid; >> >> int is_ruby_native_thread() { >> return NATIVETHREAD_EQUAL(ruby_thid, NATIVETHREAD_CURRENT()); >> } >> >> And in ruby.h: >> >> #elif defined(_WIN32) || defined(_WIN32_WCE) >> typedef DWORD rb_nativethread_t; >> # define NATIVETHREAD_CURRENT() GetCurrentThreadId() >> # define NATIVETHREAD_EQUAL(t1,t2) ((t1) == (t2)) >> # define HAVE_NATIVETHREAD >> #endif >> >> So, somehow Ruby''s thread ID is no longer the same as what it originally >> started at? How can that be? >> >> Regards, >> >> Dan >> >> # test.rb >> require ''windows/console'' >> require ''windows/sound'' >> include Windows::Console >> include Windows::Sound >> >> CtrlHandler = Win32::API::Callback.new(''L'', ''I''){ |ctrl_type| >> case ctrl_type >> when CTRL_C_EVENT >> puts "Ctrl-C event" >> Beep(750, 300) >> return true >> when CTRL_CLOSE_EVENT >> Beep(600, 200) >> puts "Ctrl-Close event" >> return true >> when CTRL_BREAK_EVENT >> Beep(900, 200) >> puts "Ctrl-Break event" >> return false >> when CTRL_LOGOFF_EVENT >> Beep(1000, 200) >> puts "Ctrl-Logoff event" >> return false >> when CTRL_SHUTDOWN_EVENT >> Beep(750, 500) >> puts("Ctrl-Shutdown event") >> return false >> else >> return false >> end >> } >> >> if SetConsoleCtrlHandler(CtrlHandler, TRUE) >> printf( "\nThe Control Handler is installed.\n" ) >> printf( "\n -- Now try pressing Ctrl+C or Ctrl+Break, or" ) >> printf( "\n try logging off or closing the console...\n" ) >> printf( "\n(...waiting in a loop for events...)\n\n" ) >> >> while true >> end >> else >> printf( "\nERROR: Could not set control handler") >> end >> _______________________________________________ >> win32utils-devel mailing list >> win32utils-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/win32utils-devel >> > _______________________________________________ > win32utils-devel mailing list > win32utils-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/win32utils-devel >