[ruby-core:30116] Re: [Bug #2488] thread usage can result in bad HANDLE

Hello,

2010/5/6, Caleb Clausen <[e-mail]>:
> I don't understand win32 programming that well...

Me too.

> Why is it necessary to re-check that intr is set to what it was set to
> just two lines before? I assume it might be changed by the action of
> another thread, but if that's the case, wouldn't it be better to just
> check that field once while inside the global_vm_lock? (ie move the
> lock/unlock to be around the whole if statement.)

Yes, you are right.
I think first that it is good to avoid native_mutex_lock() as much as possible.
Now, I realize the condition (th && !intr) is fulfilled in a only few moments.

But if we delete check of outside, new check of mutex's existence will
be needed.
I'm afraid that it doesn't make sense from the standpoint of cost down.

> For that matter, shouldn't ruby be using the api provided by windows
> (WaitForSingleObject, apparently) to check the state of this 'event
> object' (really a semaphore)? If you do it that way, then maybe the
> global_vm_lock doesn't need to be touched.

I guess it is not very good idea.
Because th->native_thread_data.interrupt_event can be destroyed
by native_thread_destroy() between check and lock, but GVL can't.

And if ruby use  'event object', we should insert locking to somewhere
such as thread_cleanup_func(), but lock with GVL is in thread_start_func_2()
already. There is not a new cost.

But if you know the use case the lock can be harm, I'm glad to change it.

-- 
wanabe