You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe the implementation of InterruptScriptThread is not correct. In our application when the method is called it causes a deadlock. It's because the script engine hijacks our thread by setting its context (lethal SuspendThread/SetThreadContext/ResumeThread combination). This prevents our thread to clean-up safely. I think the script interruption is supposed to work in a cooperative way, as hinted in this FAQ:
InterruptScriptThread only instructs the script engine to stop executing code at the next opportunity. The call sets a flag that the script engine only checks when executing code.
and
IActiveScript::InterruptScriptThread will return E_INVALIDARG if an interrupt is already pending in the script thread (ie. waiting for the next statement to be executed)…
I think you should instruct the Ruby VM somehow to abort the execution at the next opportunity. If this is not possible (e.g. there is no API for it) then it would IMHO be better to indicate that the request is not supported (E_NOTIMPL) than fiddling with context of a thread you don't own.
The text was updated successfully, but these errors were encountered:
@arton: Did you, by any chance, have time to look at this issue? I'm trying to use your implementation and it failes on the threads, it kills the script.
Hi tukanos,
I'd like to fix this issue. However, in this quarter, yes, I have no time to tackle it.
I wonder if you could wait until I can do it or PR the code to me.
I believe the implementation of
InterruptScriptThread
is not correct. In our application when the method is called it causes a deadlock. It's because the script engine hijacks our thread by setting its context (lethalSuspendThread
/SetThreadContext
/ResumeThread
combination). This prevents our thread to clean-up safely. I think the script interruption is supposed to work in a cooperative way, as hinted in this FAQ:and
I think you should instruct the Ruby VM somehow to abort the execution at the next opportunity. If this is not possible (e.g. there is no API for it) then it would IMHO be better to indicate that the request is not supported (
E_NOTIMPL
) than fiddling with context of a thread you don't own.The text was updated successfully, but these errors were encountered: