OK. I will use isolates. Can I share the global object between isolates?

Am Montag, 8. April 2013 11:14:57 UTC+2 schrieb Jakob Kummerow:
>
> I didn't realize that you had several threads running at the same time in 
> the same isolate. V8 is not designed for this, and you could hit all sorts 
> of "interesting" behavior. You should use a separate isolate for each 
> thread.
>
>
> On Mon, Apr 8, 2013 at 10:59 AM, Laszlo Szakony 
> <[email protected]<javascript:>
> > wrote:
>
>> Hi Jakob,
>>
>> thank you for the detailed explanation.
>> You are right. The execution was terminated after a long time with 
>> sleep(500), and with sleep(1) the execution terminated in a few seconds. 
>> Though my formulation of title of theme was not correct, your answer 
>> helped me to analyse the real problem.
>> I don´t want to terminate the thread(s) running the isolate. I just want 
>> to terminate the execution the currently running JS function in the isolate.
>> Using sleep() was just a tool setup a reproducible test environment. The 
>> tests in my system were setup as follows:
>> - Start 20 isolates running the JS function "function f() { 
>> while(true){sleep(10);} } f();"
>> - Call v8::TerminateExecution(thread_id) for the 20 isolates running the 
>> same JS code.
>> - PROBLEM: All but one isolate terminated the execution of JS code in a 
>> few seconds.
>> - The remaining isolate continued running the JS code, even calling 
>> v8::TerminateExecution(thread_id) several times.
>>
>> So I modified in 'cctest' the file 'test-thread-termination.cc' to 
>> reproduce the behavior, but without success. It worked fine.
>> But I observed, that terminating the first isolate happens mach faster, 
>> then terminating the remaining ones.
>> The test is as follows:
>> - Start 3 isolates running the JS funciton "function f() { sleep(1000); 
>> while(true){sleep(1);} } f();"
>> - Call v8::TerminateExecution(thread_id) for the 3 isolates running the 
>> same JS code.
>> - I stored the looping count in the while loop, and printed at the end. 
>> Here are the results:
>>
>> Seconds      Message
>> ====================================================
>> 00.000  Started Thread : 2
>> 00.007  Thread 2 sleeping for 1000 millisec
>> 00.007  Started Thread : 3
>> 00.008  Thread 3 sleeping for 1000 millisec
>> 00.009  Started Thread : 4
>> 00.017  Thread 4 sleeping for 1000 millisec
>> 00.018  Terminating Thread 2
>> 00.019  Terminating Thread 3
>> 00.021  Terminating Thread 4
>> 01.007  Thread 2 sleeping over for 1000 millisec
>> 01.009  Thread 3 sleeping over for 1000 millisec
>> 01.018  Thread 4 sleeping over for 1000 millisec
>> 01.133  Finished Thread : 2 with loop count : 0
>> 04.110  Finished Thread : 4 with loop count : 2939
>> 04.111  Finished Thread : 3 with loop count : 2951
>> 04.113  Sum of loop counts : 5890
>>
>> I repeated the test with different number of isolates, the result was 
>> always the same:
>>
>> 00.000  Started Thread : 2
>> 00.012  Thread 2 sleeping for 1000 millisec
>> 00.013  Started Thread : 3
>> 00.018  Thread 3 sleeping for 1000 millisec
>> 00.018  Started Thread : 4
>> 00.020  Thread 4 sleeping for 1000 millisec
>> 00.020  Started Thread : 5
>> 00.032  Started Thread : 6
>> 00.034  Thread 6 sleeping for 1000 millisec
>> 00.044  Thread 5 sleeping for 1000 millisec
>> 00.045  Terminating Thread 2
>> 00.046  Terminating Thread 5
>> 00.047  Terminating Thread 3
>> 00.048  Terminating Thread 6
>> 00.048  Terminating Thread 4
>> 01.012  Thread 2 sleeping over for 1000 millisec
>> 01.018  Thread 3 sleeping over for 1000 millisec
>> 01.020  Thread 4 sleeping over for 1000 millisec
>> 01.044  Thread 6 sleeping over for 1000 millisec
>> 01.045  Thread 5 sleeping over for 1000 millisec
>> 01.065  Finished Thread : 2 with loop count : 0
>> 02.568  Finished Thread : 3 with loop count : 1475
>> 02.570  Finished Thread : 6 with loop count : 1471
>> 02.572  Finished Thread : 5 with loop count : 1471
>> 02.577  Finished Thread : 4 with loop count : 1475
>> 02.580  Sum of loop counts : 5892
>>
>> Interesting is, that the sum of the loop counts seems to be constant.
>> Would it mean that running 20 isolates terminates faster that running 2 
>> or 3?
>>
>> I suspect, that in my application the remaining isolate that does not 
>> terminate the execution of the running JS code is the "first" isolate.
>>
>> Do you have any idea, what conditions could cause to prevent 
>> the termination of execution of JS Code?
>> Timing constraints, debugging ports, common global object, ...?
>>
>> Thank you,
>>
>> Laszlo
>>
>> On Thursday, 4 April 2013 15:45:25 UTC+2, Jakob Kummerow wrote:
>>
>>> TerminateExecution() does not send a kill signal to the process/thread 
>>> or anything like that. It sets a flag that requests termination of 
>>> currently running generated code for JS functions. Execution in loops isn't 
>>> necessarily terminated immediately, several iterations of the loop may 
>>> still happen (this depends on the length of the loop). The idea is that you 
>>> can quickly gain control over long-running scripts ("Your browser tab is 
>>> hanging, would you like to stop it?"). V8 does not have, and in my opinion 
>>> does not need, a mechanism to interrupt v8::internal::OS::Sleep(), as this 
>>> is never called from JS (in vanilla V8).
>>>
>>> The reason your alternative "DoSleep" implementation terminates much 
>>> quicker is because the C++ function finishes much sooner, returning control 
>>> to JS, which in turn is interrupted after a couple of loop iterations. I'm 
>>> willing to bet that if you reduce the sleeping interval from 500ms to, say, 
>>> 1ms in the other implementation, you'll observe much quicker termination 
>>> there (and, conversely, if you wait long enough, the 500ms version will 
>>> terminate eventually).
>>>
>>> Long story short: v8::TerminateExecution() is not designed to interrupt 
>>> v8::internal::OS::Sleep(), nor any other function or FunctionTemplate 
>>> implemented in C++. If you want to be able to have sleeping threads and 
>>> terminate them, you'll have to use either another sleep implementation, or 
>>> another way to request termination. (Where "use another" means "implement 
>>> your own".)
>>>
>>>
>>> On Thu, Apr 4, 2013 at 10:16 AM, Laszlo Szakony <[email protected]>wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm using v8 - v8_13185_v3.15.11 - on Windows, Win7 64bit in 
>>>> multi-threaded environment: several scripts are running parallel. 
>>>> At an arbitrary time I want to terminate certain running scripts or 
>>>> maybe all from another thread. Some of the scripts may have infinite 
>>>> loops. 
>>>> Everything works fine, until some scripts call dosleep() in a 
>>>> FunctionTemplate defined as follows: 
>>>>
>>>> (In thread script[n]) 
>>>>
>>>> v8::Handle<v8::Value> DoSleep(const v8::Arguments& args) {****
>>>>
>>>>   int millisec = args[0]->ToInt32()->**Int32Value();****
>>>>
>>>>   if (millisec)****
>>>>
>>>>   {****
>>>>
>>>>     v8::Unlocker unlock;****
>>>>
>>>>     v8::internal::OS::Sleep(**millisec);****
>>>>
>>>>   }****
>>>>
>>>>   return v8::Undefined();****
>>>>
>>>> }****
>>>>
>>>> …****
>>>>
>>>> v8::Handle<v8::ObjectTemplate> global = v8::ObjectTemplate::New();****
>>>>
>>>> global->Set(v8::String::New("**dosleep"), v8::FunctionTemplate::New(**
>>>> DoSleep));****
>>>>
>>>> …****
>>>>
>>>> The JavaScript Code looks sg. like this:****
>>>>
>>>> v8::Script::Compile(v8::**String::New("function f() { while(true) 
>>>> {dosleep(500);} } f()"))->Run();****
>>>>
>>>> ** **
>>>>
>>>> In the main thread I call:****
>>>>
>>>> v8::Locker locker;****
>>>>
>>>> for (int i = 0; i < kThreads; i++) {****
>>>>
>>>>   v8::V8::TerminateExecution(**threads[i]->GetV8ThreadId());****
>>>>
>>>> ** **
>>>>
>>>> The threads calling dosleep() won`t terminate. If I change the 
>>>> DoSleep() Function() to:****
>>>>
>>>> v8::Handle<v8::Value> DoSleep(const v8::Arguments& args) {****
>>>>
>>>>   int millisec = args[0]->ToInt32()->**Int32Value();****
>>>>
>>>>   if (millisec)****
>>>>
>>>>   {****
>>>>
>>>>     v8::Unlocker unlock;****
>>>>
>>>>     for (int i = count; i--;) for (int j = 1000; j--;) ;****
>>>>
>>>>   }****
>>>>
>>>>   return v8::Undefined();****
>>>>
>>>> }
>>>>
>>>>
>>>> then the threads calling dosleep() will be terminated.****
>>>>
>>>> I have modified test-thread-termination.cc to demonstrate the behavior. 
>>>> After replacing test-thread-termination.cc with the attached one and 
>>>> compiling of ccttest the tests can be called by:****
>>>>
>>>> C:\v8_13185_v3.15.11\build\**Release>cctest test-thread-termination/**
>>>> TerminateMultipleV8ThreadsWith**DelayDefaultIsolate => OK****
>>>>
>>>> C:\v8_13185_v3.15.11\build\**Release>cctest test-thread-termination/**
>>>> TerminateMultipleV8ThreadsWith**SleepDefaultIsolate => Failed: no 
>>>> termination****
>>>>
>>>>
>>>> Is this a bug? If not, how can I terminate scripts calling sleep()?
>>>>
>>>>
>>>> Thank you,
>>>>
>>>> Laszlo
>>>>
>>>> -- 
>>>> -- 
>>>> v8-users mailing list
>>>> [email protected]
>>>>
>>>> http://groups.google.com/**group/v8-users<http://groups.google.com/group/v8-users>
>>>> --- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "v8-users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to v8-users+u...@**googlegroups.com.
>>>>
>>>> For more options, visit 
>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>  
>>>>  
>>>>
>>>
>>>  -- 
>> -- 
>> v8-users mailing list
>> [email protected] <javascript:>
>> http://groups.google.com/group/v8-users
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

-- 
-- 
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to