Thanks for the reply. As Kentaro said, Blink uses TerminateExecution only when it tries to terminate a worker thread forcibly. The isolation will soon be disposed, and the "recovering" functionality is actually harmful for us.
main -----T------------ worker --*E1**--*E2****** T: Call TerminateExecution with the worker isolate (on the main thread) E1: bottom-most script evaluation (* means running) E2: bottom-most script evaluation (* means running) In this case, the main thread wants to terminate the worker thread, but it calls TerminateExecution only once so it E2 runs potentially forever. If there is an option that ensures that future v8 calls will fail whenever possible and the v8::TryCatch scope around that will return true for v8::TryCatch::HasCaught, then we'll be happy. Is it possible? On Mon, Nov 19, 2018 at 7:27 PM Yutaka Hirano <yhir...@chromium.org> wrote: > Hi, > > Let's consider the following sequence. > > -----------------------------> time > > main -----T------------ > worker --*E1**--*E2***--- > > T: Call TerminateExecution with the worker isolate (on the main thread) > E1: bottom-most script evaluation (* means running) > E2: bottom-most script evaluation (* means running) > > In this case, E1 is terminated due to TerminateExecution, but E2 runs > normally (i.e., may return a non-empty value) because "the isolate is good > to be re-used again", right? > > Another question: If E1 starts running after TerminateExecution is called, > what happens? > > main T----------------- > worker --*E1**----------- > > T: Call TerminateExecution with the worker isolate (on the main thread) > E1: bottom-most script evaluation (* means running) > > Will E1 be aborted due to a past TerminateExecution call, or will it run > because "the isolate is good to be re-used again"? > > Thanks, > > > On Mon, Nov 19, 2018 at 3:28 PM Yang Guo <yang...@chromium.org> wrote: > >> Sorry. I should have been more explicit here. My image of the stack is >> growing bottom up. So A is the bottom-most V8 call. >> >> Yang >> >> On Mon, Nov 19, 2018 at 5:42 AM Yutaka Hirano <yhir...@chromium.org> >> wrote: >> >>> Hi, >>> >>> I found I don't understand the direction. If there are only two levels, >>> say blink-calls-v8(A)-calls-blink-calls-v8(B), which is the bottom-most v8 >>> call, A or B? >>> >>> Thanks, >>> >>> On Fri, Nov 16, 2018 at 6:30 PM Yutaka Hirano <yhir...@chromium.org> >>> wrote: >>> >>>> Hi Yang, >>>> >>>> Thank you for the information! >>>> Sorry for the late response. I will send a reply next week. >>>> >>>> Thanks, >>>> >>>> >>>> On Thu, Nov 15, 2018 at 9:33 PM Kentaro Hara <hara...@chromium.org> >>>> wrote: >>>> >>>>> I found that at the only place Isolate::TerminateExecution is called >>>>>> <https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/workers/worker_thread.cc?type=cs&sq=package:chromium&g=0&l=415> >>>>>> from >>>>>> blink, V8 is not even running. That would mean that we don't have to >>>>>> worry >>>>>> about any of this? >>>>> >>>>> >>>>> At that place the main thread (which is not running V8) is calling >>>>> TerminateExecution to terminate a running worker thread. The concern is on >>>>> the worker thread. >>>>> >>>>> >>>>> On Thu, Nov 15, 2018 at 6:51 PM Yang Guo <yang...@chromium.org> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I found that at the only place Isolate::TerminateExecution is called >>>>>> <https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/workers/worker_thread.cc?type=cs&sq=package:chromium&g=0&l=415> >>>>>> from >>>>>> blink, V8 is not even running. That would mean that we don't have to >>>>>> worry >>>>>> about any of this? >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Yang >>>>>> >>>>>> On Wed, Nov 14, 2018 at 10:00 AM Yang Guo <yang...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> I filed a bug for the slightly counter-intuitive behavior I >>>>>>> mentioned: https://bugs.chromium.org/p/v8/issues/detail?id=8455 >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Yang >>>>>>> >>>>>>> On Wed, Nov 14, 2018 at 9:01 AM Yang Guo <yang...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> When you terminate execution in V8, we abort execution until the >>>>>>>> bottom-most call into V8. If you have re-entries into V8, V8 always >>>>>>>> returns >>>>>>>> empty results until the bottom-most call into V8. On the Blink side on >>>>>>>> the >>>>>>>> stack of the re-entries, you can try to call into V8 before returning, >>>>>>>> but >>>>>>>> that will simply return empty results. v8::TryCatch scopes along the >>>>>>>> way >>>>>>>> will return true for v8::TryCatch::HasCaught and >>>>>>>> v8::TryCatch::HasTerminated. Isolate::IsExecutionTerminating returns >>>>>>>> true. >>>>>>>> >>>>>>>> As soon as we reach the bottom-most call, we return with an empty >>>>>>>> value as well. The v8::TryCatch scope around that will return true for >>>>>>>> v8::TryCatch::HasCaught and v8::TryCatch::HasTerminated, but >>>>>>>> Isolate::IsExecutionTerminating will return false (even if you are >>>>>>>> still >>>>>>>> inside this outer-most v8::TryCatch scope), because you can safely call >>>>>>>> into V8 again, from here on. I actually find this a bit >>>>>>>> counter-intuitive, >>>>>>>> and it might be better to have Isolate::IsExecutionTerminating return >>>>>>>> true, >>>>>>>> until we leave the outer-most v8::TryCatch. Though implementing that >>>>>>>> seems >>>>>>>> a bit annoying. >>>>>>>> >>>>>>>> So what you are observing is that you have a non-reentry call to >>>>>>>> execute the worker. That terminates, and you then have another >>>>>>>> non-reentry >>>>>>>> call. That is working as intended though. Once you have left V8 through >>>>>>>> termination across all re-entries, the isolate is good to be re-used >>>>>>>> again. >>>>>>>> I think the correct way to fix your issue is to, at non-reentry calls, >>>>>>>> *always >>>>>>>> check for v8::TryCatch::HasTerminated, and use that to guide the >>>>>>>> following >>>>>>>> control flow*. >>>>>>>> >>>>>>>> To answer your questions: >>>>>>>> >>>>>>>>> 1. What happens if the isolate is forcibly terminated (from >>>>>>>>> another thread) while running a script? Will an exception be thrown? >>>>>>>>> Is a >>>>>>>>> v8::TryCatch catches the exception? >>>>>>>> >>>>>>>> Internally we throw a special exception that cannot be caught by >>>>>>>> javascript. This exception causes execution to abort until we arrive >>>>>>>> at the >>>>>>>> first (non-reentry) call into V8. >>>>>>>> >>>>>>>> 2. What happens if we try to run a script when the isolate has >>>>>>>>> already been terminated? >>>>>>>> >>>>>>>> If you completely exited V8 back to the first non-reentry call, you >>>>>>>> can safely use the isolate again. >>>>>>>> >>>>>>>> 3. What happens if v8 calls blink code, the isolate is forcibly >>>>>>>>> terminated and then the control is back to v8? >>>>>>>> >>>>>>>> The termination exception is propagated back to V8, causes the >>>>>>>> current execution to abort, so that we return an empty value to blink >>>>>>>> as >>>>>>>> soon as possible. If this blink frame is called from V8, then calling >>>>>>>> into >>>>>>>> V8 will only result in empty values. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Yang >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Nov 10, 2018 at 12:15 AM Adam Klein <ad...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Thu, Nov 8, 2018 at 8:21 PM Yutaka Hirano <yhir...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> > As to the problem itself, I have a clarifying questions: >>>>>>>>>> doesn't Blink already have some choke point to determine whether >>>>>>>>>> it's "ok >>>>>>>>>> to call script now"? If so that'd be a more natural place to add this >>>>>>>>>> handling than TryCatch. >>>>>>>>>> >>>>>>>>>> No, there isn't such a point. To make matters worse, some >>>>>>>>>> call-sites don't check errors because they don't care. >>>>>>>>>> >>>>>>>>>> Sorry for the ignorance but I would like to know V8's policy on >>>>>>>>>> termination. >>>>>>>>>> >>>>>>>>>> 1. What happens if the isolate is forcibly terminated (from >>>>>>>>>> another thread) while running a script? Will an exception be thrown? >>>>>>>>>> Is a >>>>>>>>>> v8::TryCatch catches the exception? >>>>>>>>>> 2. What happens if we try to run a script when the isolate has >>>>>>>>>> already been terminated? >>>>>>>>>> 3. What happens if v8 calls blink code, the isolate is forcibly >>>>>>>>>> terminated and then the control is back to v8? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I'm not intimately familiar with the details here. Yang or Toon, >>>>>>>>> perhaps you have more insight? >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Nov 9, 2018 at 5:30 AM Adam Klein <ad...@chromium.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Adding a couple more V8 folks who may have thoughts. >>>>>>>>>>> >>>>>>>>>>> On Thu, Nov 8, 2018 at 1:59 AM Kentaro Hara < >>>>>>>>>>> hara...@chromium.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Thu, Nov 8, 2018 at 1:10 AM Yuki Shiino < >>>>>>>>>>>> yukishi...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> +adamk, cbruni to get more attention from V8 team. This needs >>>>>>>>>>>>> V8 team's support. >>>>>>>>>>>>> >>>>>>>>>>>>> Actually, I intended haraken's (a3) at my proposal (a), but >>>>>>>>>>>>> I'm afraid that changing an existing API HasCaught() would break >>>>>>>>>>>>> backward >>>>>>>>>>>>> compatibility. So, I'm also proposing to add a new V8 API like >>>>>>>>>>>>> v8::TryCatch::HasPendingException or >>>>>>>>>>>>> v8::TryCatch::HasCaughtOrTerminated or >>>>>>>>>>>>> whatever we call it. >>>>>>>>>>>>> >>>>>>>>>>>>> By the way, the example code is just an example. Usually we >>>>>>>>>>>>> don't have two TryCatch blocks next to each other, and Blink is >>>>>>>>>>>>> rethrowing >>>>>>>>>>>>> the exception in most cases. I just forgot to write rethrow in >>>>>>>>>>>>> the >>>>>>>>>>>>> example. That's not a point. Let me revise the example. >>>>>>>>>>>>> >>>>>>>>>>>>> Main thread: >>>>>>>>>>>>> v8::Isolate* worker_isolate = ...; >>>>>>>>>>>>> worker_isolate->TerminateExecution(); // Terminates the >>>>>>>>>>>>> worker isolate. >>>>>>>>>>>>> >>>>>>>>>>>>> Worker thread (worker isolate): >>>>>>>>>>>>> Foo(); // The v8::Isolate terminates during execution of >>>>>>>>>>>>> Foo. >>>>>>>>>>>>> Bar(); >>>>>>>>>>>>> >>>>>>>>>>>>> where Foo and Bar are the followings. >>>>>>>>>>>>> >>>>>>>>>>>>> void Foo() { >>>>>>>>>>>>> v8::TryCatch try_catch1(isolate); >>>>>>>>>>>>> // Call V8 APIs. The v8::Isolate gets terminated at >>>>>>>>>>>>> this point. >>>>>>>>>>>>> if (try_catch1.HasCaught()) { // => true due to the >>>>>>>>>>>>> termination exception. >>>>>>>>>>>>> // Rethrow or report the error to global error >>>>>>>>>>>>> handlers. >>>>>>>>>>>>> return; >>>>>>>>>>>>> } >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> void Bar() { >>>>>>>>>>>>> v8::TryCatch try_catch2(isolate); >>>>>>>>>>>>> // Call V8 APIs. V8 APIs fail because the isolate is >>>>>>>>>>>>> terminating. >>>>>>>>>>>>> if (try_catch2.HasCaught()) { // => false because no >>>>>>>>>>>>> new exception is thrown inside |try_catch2| scope. >>>>>>>>>>>>> // Rethrow or report the error to global error >>>>>>>>>>>>> handlers. >>>>>>>>>>>>> return; >>>>>>>>>>>>> } >>>>>>>>>>>>> // Blink reaches here. :( >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hmm, I'm a bit confused. >>>>>>>>>>>> >>>>>>>>>>>> If Foo() rethrows the exception, why does the worker thread >>>>>>>>>>>> continue execution and call Bar()? That will cause a problem even >>>>>>>>>>>> when the >>>>>>>>>>>> worker is not terminated (because the worker continues execution >>>>>>>>>>>> ignoring >>>>>>>>>>>> the thrown exception)...? >>>>>>>>>>>> >>>>>>>>>>>> Also I might want to understand how widely the problem is >>>>>>>>>>>> happening. First of all, it is not realistic to handle worker's >>>>>>>>>>>> sudden >>>>>>>>>>>> termination in 100% cases (unless we add checks to all V8 API >>>>>>>>>>>> calls in the >>>>>>>>>>>> Blink code base). So the best thing we can do is to insert the >>>>>>>>>>>> termination >>>>>>>>>>>> check to places that may call scripts (e.g., V8ScriptRunner, >>>>>>>>>>>> EventListener, >>>>>>>>>>>> Promise resolve / reject etc) and reduce the crash rate. We could >>>>>>>>>>>> introduce >>>>>>>>>>>> HasCaughtOrTerminated() if it helps to reduce the crash rate, but >>>>>>>>>>>> I want to >>>>>>>>>>>> make sure that assumption is correct. My intuition is that it will >>>>>>>>>>>> be more >>>>>>>>>>>> useful to identify places that may call scripts often and insert >>>>>>>>>>>> the >>>>>>>>>>>> termination checks if missing. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'd similarly like to understand how much this happens in >>>>>>>>>>> practice. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> A proposed solution looks like the following. >>>>>>>>>>>>> >>>>>>>>>>>>> v8::TryCatch try_catch(isolate); >>>>>>>>>>>>> // ... >>>>>>>>>>>>> if (try_catch.*HasCaughtOrTerminated*()) { >>>>>>>>>>>>> v8::Local<v8::Exception> exception = try_catch. >>>>>>>>>>>>> *CaughtExceptionOrTerminationException*(); >>>>>>>>>>>>> // Do a job with |exception|. >>>>>>>>>>>>> return; >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> where HasCaughtOrTerminated returns true when the isolate is >>>>>>>>>>>>> terminating even if no exception is thrown inside the TryCatch >>>>>>>>>>>>> scope, and >>>>>>>>>>>>> CaughtExceptionOrTerminationException returns a thrown exception >>>>>>>>>>>>> if an >>>>>>>>>>>>> exception is thrown inside the TryCatch scope or the termination >>>>>>>>>>>>> exception >>>>>>>>>>>>> if the isolate is terminating. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> As to the problem itself, I have a clarifying questions: doesn't >>>>>>>>>>> Blink already have some choke point to determine whether it's "ok >>>>>>>>>>> to call >>>>>>>>>>> script now"? If so that'd be a more natural place to add this >>>>>>>>>>> handling than >>>>>>>>>>> TryCatch. >>>>>>>>>>> >>>>>>>>>>> - Adam >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Yuki Shiino >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2018年11月8日(木) 17:38 Kentaro Hara <hara...@chromium.org>: >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, I got it :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> My proposal would be: >>>>>>>>>>>>>> >>>>>>>>>>>>>> (a3) Make HasCaught() return true when the isolate is >>>>>>>>>>>>>> terminated. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not sure if (a) or (a2) is a good idea because the fact >>>>>>>>>>>>>> that we didn't call ReThrow() means that we (intentionally) >>>>>>>>>>>>>> suppressed the >>>>>>>>>>>>>> exception. Thoughts? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Nov 7, 2018 at 9:51 PM Yuki Shiino < >>>>>>>>>>>>>> yukishi...@chromium.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Are you assuming that the worker is terminated while it's >>>>>>>>>>>>>>>> calling DoSomethingElseWithV8()? If yes, why does HasCaught() >>>>>>>>>>>>>>>> not return >>>>>>>>>>>>>>>> true? If no, what's a problem of continuing execution? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No, the worker is terminated while DoSomethingWithV8 >>>>>>>>>>>>>>> (without "Else"), and Blink continues running more V8 code at >>>>>>>>>>>>>>> DoSomethingElseWithV8. Two pieces of code run consecutively. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Worker thread (worker isolate): >>>>>>>>>>>>>>> { >>>>>>>>>>>>>>> v8::TryCatch try_catch(isolate); >>>>>>>>>>>>>>> DoSomethingWithV8(); // The Isolate terminates here. >>>>>>>>>>>>>>> if (try_catch.HasCaught()) { // => true due to >>>>>>>>>>>>>>> termination >>>>>>>>>>>>>>> // Handle error or termination. >>>>>>>>>>>>>>> return; >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> { >>>>>>>>>>>>>>> v8::TryCatch try_catch(isolate); >>>>>>>>>>>>>>> DoSomethingElseWithV8(); // V8 APIs fail because the >>>>>>>>>>>>>>> Isolate is terminating. >>>>>>>>>>>>>>> if (try_catch.HasCaught()) { // => false because no >>>>>>>>>>>>>>> new exception is thrown inside the v8::TryCatch. >>>>>>>>>>>>>>> return; // Blink doesn't reach here. >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> // Blink reach here instead. :( >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> IIUC, the second try_catch.HasCaught() doesn't return true >>>>>>>>>>>>>>> because there is no new exception thrown inside the >>>>>>>>>>>>>>> v8::TryCatch scope, >>>>>>>>>>>>>>> although V8 APIs fail inside DoSomethingElseWithV8 due to a >>>>>>>>>>>>>>> pending >>>>>>>>>>>>>>> termination exception. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> Yuki Shiino >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2018年11月8日(木) 3:18 Kentaro Hara <hara...@chromium.org>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sorry, I'm not sure if I understand your example... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Nov 7, 2018 at 2:21 AM Yutaka Hirano < >>>>>>>>>>>>>>>> yhir...@chromium.org> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> +ricea@ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Nov 7, 2018 at 6:44 PM Yuki Shiino < >>>>>>>>>>>>>>>>> yukishi...@chromium.org> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi V8-team and platform-architecture-dev, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> TL;DR: We'd like to extend v8::TryCatch APIs a little. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We're having an issue how to handle worker termination, >>>>>>>>>>>>>>>>>> i.e. v8::Isolate termination. Roughly speaking, the >>>>>>>>>>>>>>>>>> situation is like >>>>>>>>>>>>>>>>>> below. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Main thread: >>>>>>>>>>>>>>>>>> v8::Isolate* worker_isolate = ...; >>>>>>>>>>>>>>>>>> worker_isolate->TerminateExecution(); // Terminates >>>>>>>>>>>>>>>>>> the worker isolate. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Worker thread (worker isolate): >>>>>>>>>>>>>>>>>> v8::TryCatch try_catch(isolate); >>>>>>>>>>>>>>>>>> DoSomethingWithV8(); // The Isolate terminates here. >>>>>>>>>>>>>>>>>> if (try_catch.HasCaught()) { // => true due to >>>>>>>>>>>>>>>>>> termination >>>>>>>>>>>>>>>>>> // Handle error or termination. >>>>>>>>>>>>>>>>>> return; >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> No problem so far. Worker thread MUST NOT run any V8 >>>>>>>>>>>>>>>>>> code no longer because the Isolate is terminating. However, >>>>>>>>>>>>>>>>>> Blink is not >>>>>>>>>>>>>>>>>> perfect, and it's pretty tough for Blink to stop everything >>>>>>>>>>>>>>>>>> with 100% >>>>>>>>>>>>>>>>>> correctness. Occasionally (or rarely) Blink continues >>>>>>>>>>>>>>>>>> running more V8 code >>>>>>>>>>>>>>>>>> like below. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Worker thread (worker isolate): >>>>>>>>>>>>>>>>>> v8::TryCatch try_catch(isolate); >>>>>>>>>>>>>>>>>> DoSomethingElseWithV8(); >>>>>>>>>>>>>>>>>> if (try_catch.HasCaught()) { // => false because no >>>>>>>>>>>>>>>>>> new exception is thrown inside the v8::TryCatch. >>>>>>>>>>>>>>>>>> return; // Blink doesn't reach here. >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> // Blink reach here instead. :( >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> If v8::TryCatch::HasCaught() returned true, Blink would >>>>>>>>>>>>>>>>>> be able to handle it as error and Blink would work much >>>>>>>>>>>>>>>>>> better than now >>>>>>>>>>>>>>>>>> (Blink is now crashing). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Are you assuming that the worker is terminated while it's >>>>>>>>>>>>>>>> calling DoSomethingElseWithV8()? If yes, why does HasCaught() >>>>>>>>>>>>>>>> not return >>>>>>>>>>>>>>>> true? If no, what's a problem of continuing execution? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So, proposals here are something like below (not yet so >>>>>>>>>>>>>>>>>> concrete). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> a) Make v8::TryCatch::HasCaught() return true if there >>>>>>>>>>>>>>>>>> already exists a pending exception. (Maybe this is no good.) >>>>>>>>>>>>>>>>>> b) Make a new API like >>>>>>>>>>>>>>>>>> v8::TryCatch::HasPendingException() and make it return true. >>>>>>>>>>>>>>>>>> Blink >>>>>>>>>>>>>>>>>> rewrites all HasCaught() to the new one. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Similarly, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> a2) Make v8::TryCatch::Exception() return a pending >>>>>>>>>>>>>>>>>> exception if there already exists. >>>>>>>>>>>>>>>>>> b2) Make a new API like v8::TryCatch::PendingException() >>>>>>>>>>>>>>>>>> and make it return a thrown exception or pending exception >>>>>>>>>>>>>>>>>> in the isolate >>>>>>>>>>>>>>>>>> if any. Blink rewrites all Exception() to the new one. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> What do you think of the issue and proposals? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>> Yuki Shiino >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> You received this message because you are subscribed to >>>>>>>>>>>>>>>>> the Google Groups "platform-architecture-dev" group. >>>>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails >>>>>>>>>>>>>>>>> from it, send an email to >>>>>>>>>>>>>>>>> platform-architecture-dev+unsubscr...@chromium.org. >>>>>>>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>>>>>>> platform-architecture-...@chromium.org. >>>>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABihn6ER8q9QABC3ROCSkm6V4w%2BDb0xEqRvjgzwBpMG9DmiG1Q%40mail.gmail.com >>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABihn6ER8q9QABC3ROCSkm6V4w%2BDb0xEqRvjgzwBpMG9DmiG1Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Kentaro Hara, Tokyo, Japan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Kentaro Hara, Tokyo, Japan >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Kentaro Hara, Tokyo, Japan >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>> Google Groups "platform-architecture-dev" group. >>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>> it, send an email to >>>>>>>>>>>> platform-architecture-dev+unsubscr...@chromium.org. >>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>> platform-architecture-...@chromium.org. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jx51JXHEt0H9z%3DzT%3D0GnhDf79QjhGtVxRc%3Dy-RXjHXUyw%40mail.gmail.com >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jx51JXHEt0H9z%3DzT%3D0GnhDf79QjhGtVxRc%3Dy-RXjHXUyw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "platform-architecture-dev" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to >>>>>>>>>> platform-architecture-dev+unsubscr...@chromium.org. >>>>>>>>>> To post to this group, send email to >>>>>>>>>> platform-architecture-...@chromium.org. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABihn6GKuTUs5UfpbQ6RwXq%3DWw0dDUJkq2JLzadnesfjLG%3DStg%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABihn6GKuTUs5UfpbQ6RwXq%3DWw0dDUJkq2JLzadnesfjLG%3DStg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "platform-architecture-dev" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to >>>>>>>>> platform-architecture-dev+unsubscr...@chromium.org. >>>>>>>>> To post to this group, send email to >>>>>>>>> platform-architecture-...@chromium.org. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAEvLGcKKKdZ4-Svz7NmXdzSaL9ryQz4cPEqhTfmWEURzwTdMqQ%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAEvLGcKKKdZ4-Svz7NmXdzSaL9ryQz4cPEqhTfmWEURzwTdMqQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "platform-architecture-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to platform-architecture-dev+unsubscr...@chromium.org. >>>>>> To post to this group, send email to >>>>>> platform-architecture-...@chromium.org. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAFSTc_iBZUPpYMuUk3ouOe7cLBDizJFUjmcWuaAeVZfMBn4QqQ%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAFSTc_iBZUPpYMuUk3ouOe7cLBDizJFUjmcWuaAeVZfMBn4QqQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> >>>>> >>>>> -- >>>>> Kentaro Hara, Tokyo, Japan >>>>> >>>>> -- >>>>> -- >>>>> v8-users mailing list >>>>> v8-users@googlegroups.com >>>>> 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+unsubscr...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "platform-architecture-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to platform-architecture-dev+unsubscr...@chromium.org. >>> To post to this group, send email to >>> platform-architecture-...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABihn6H0_3BFq5S2wv5Y8CDyW%3Dv-HjwskH1Wds6PmTWX5akE9g%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABihn6H0_3BFq5S2wv5Y8CDyW%3Dv-HjwskH1Wds6PmTWX5akE9g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- -- v8-users mailing list v8-users@googlegroups.com 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
