The 'main thread' for a isolate is supposed to be interruptable, e.g., via Isolate::RequestInterrupt or Isolate::TerminateExecution.
I can't answer your question about how the parser / ast visitors is supposed to behave here :-/ On Mon, Oct 12, 2015 at 9:37 PM Adam Klein <ad...@chromium.org> wrote: > Which sorts of threads are expected to be interruptable? Clearly the > parser isn't (currently) interruptable in this way, since it takes in a > stack limit at construction time and never re-sets it. > > I guess the question is: is interruptability something that _all_ > AstVisitors should have, with a few exceptions? Or is it something that a > few AstVisitors care about, but most don't need to. Answering this question > will help decide what the right way of refactoring the base class stuff is. > > On Mon, Oct 12, 2015 at 12:31 PM, Jochen Eisinger <joc...@chromium.org> > wrote: > >> We use the stack limit to request interrupts from different threads, so >> checking it on a regular basis is important >> >> On Mon, Oct 12, 2015, 9:30 PM Adam Klein <ad...@chromium.org> wrote: >> >>> Any thoughts here? Caitlin is currently running into exactly the same >>> need in her do expression patch, so it'd be good to understand if we can do >>> something general here instead of having most AST visitors be Isolate-bound >>> while the few used from the parser need special duplicated code for stack >>> check handling. >>> >>> On Tue, Oct 6, 2015 at 4:17 PM, Adam Klein <ad...@chromium.org> wrote: >>> >>>> In trying to use AstExpressionVisitor in the parser, I've found the >>>> need to use an AST visitor where I don't have an Isolate handy. The >>>> DEFINE_AST_VISITOR_SUBCLASS_MEMBERS macro uses the Isolate for exactly one >>>> thing (in the method CheckStackOverflow): >>>> >>>> ... >>>> StackLimitCheck check(isolate_); >>>> if (!check.HasOverflowed()) return false; >>>> ... >>>> >>>> My question is this: is it important that the StackLimitCheck pull the >>>> stack limit out of the isolate every time CheckStackOverflow() is called? >>>> Or could we store the stack limit when AST visitors are constructed? The >>>> latter is what we already do for parsing, in ParseInfo. And from poking >>>> around the code (and in Blink) it seems like we generally only set the >>>> stack limit at thread startup. But I'm wondering if there are cases I'm not >>>> thinking about (maybe cases where a single AST visitor is used on multiple >>>> threads with the same Isolate?). >>>> >>>> - Adam >>>> >>> >>> -- >>> -- >>> v8-dev mailing list >>> v8-dev@googlegroups.com >>> http://groups.google.com/group/v8-dev >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "v8-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to v8-dev+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> -- >> v8-dev mailing list >> v8-dev@googlegroups.com >> http://groups.google.com/group/v8-dev >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to v8-dev+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > -- > v8-dev mailing list > v8-dev@googlegroups.com > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to v8-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
