From: Francis Cianfrocca [mailto:garbagecat10 / gmail.com]
Sent: Friday, June 30, 2006 6:29 AM
> On 6/29/06, Victor 'Zverok' Shepelev <vshepelev / imho.com.ua> wrote:
> >
> > Yes, It never returns. But I've thought its not a problem, because in
> the
> > code:
> > Thread.new{ sleep(10000) }
> > puts 'here'
> > sleep(10000) also virtually never returns, but code works as expected
> > (prints 'here' and exits).
> > <<<<<<<<<<<<<<<<<<<<<
> 
> sleep(10000) is a Ruby call, not a native one. It's aware that other Ruby
> threads are running. Try doing the same thing on your native thread with a
> native API (I forget what that millisecond-sleep API is on Windows)-
> you'll
> find that it blocks your program just as the event loop did.

OK, I've got it.
 
> >
> > >>>Hmmm... Ok, I'll try. But I think there must be more general solution
> > for
> > threading C extension. No?<<<<<<<<<<<<<<<<<
> >
> You're wandering into the strange land of native/green thread interaction.
> I
> won't be the one to start yet another rehash of this subject ;-). If
> you're
> trying to run the Windows GUI event loop, why not just use Ruby tk?

Because I'm doing my own GUI library :)))
BTW, here is the solution of my problem (and thank you, the solution was
very close to your advice!):
static VALUE run(VALUE _self)
{
	MSG msg;
	while (1) 
	{
		::PeekMessage(&msg, NULL, 0, 0, PM_REMOVE); //the 1st
gotcha! We need Peek, not Get message
		::TranslateMessage(&msg);
		::DispatchMessage(&msg);
		if(msg.message == WM_QUIT) break;
		rb_thread_schedule(); //second gotcha! Give ruby's scheduler
the possibility to switch
	}

	return _self;
}

V.