[Win32utils-devel] More on cross thread violation on Windows

Daniel Berger djberg96 at gmail.com
Mon Feb 18 09:02:30 EST 2008


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
> 



More information about the win32utils-devel mailing list