On Wed, Aug 17, 2016 at 4:51 PM, Abhishek Singh <[email protected]> wrote: > Hi Ben, > >> On 17-Aug-2016, at 5:43 PM, Ben Noordhuis <[email protected]> wrote: >> >> On Tue, Aug 16, 2016 at 6:22 PM, Abhishek Singh >> <[email protected]> wrote: >>> Hi Ben, >>> >>> In sample example I shared, I was trying to simulate a behaviour similar to >>> what my application(based on top of V8) saw - sleep calls were added to >>> somehow make this example artificially simulate the app. I’ve modified the >>> gist, hoping now it doesn’t create confusion. >>> >>> Here is sample output from it, I’ll explain below what they mean(annotating >>> by line no to make it easy to explain, otherwise would need ascii drawing >>> :)): >>> >>> line# Output Message >>> ==================================== >>> 1 debugger.ccTestBreakPoints179 >>> 2 debugger.ccTestBreakPoints181 >>> 3 debugger.ccSendDebugUserRequest146 >>> 4 2016-08-16.21:33:16 DebugSetBreakpointHandler >>> {"seq":0,"request_seq":1,"type":"response","command":"setbreakpoint","success":true,"body":{"type":"scriptId","breakpoint":1,"script_id":33,"line":1,"column":0,"actual_locations”: >>> >>> [{"line":1,"column":4,"script_id":33}]},"refs":[],"running":true} >>> 5 2016-08-16.21:33:18 DebugListBreakpointHandler >>> {"seq":1,"request_seq":3,"type":"response","command":"listbreakpoints","success":true,"body":{"breakpoints":[{"number":1,"line":1,"column":0,"groupId":null,"active":true,"condition":null,"actual_locations":[{"line":1,"column":4,"script_id":33}],"type":"scriptId","script_id":33}],"breakOnExceptions":false,"breakOnUncaughtExceptions":false},"refs":[],"running":true} >>> 6 debugger.ccSendDebugUserRequest148 >>> 7 2016-08-16.21:33:18SendDebugUserRequest{"type": "json", >>> "client": "Chrome Canary", "counter":0} >>> 8 debugger.ccSendDebugUserRequest162 >>> 9 2016-08-16.21:33:18 DebugListBreakpointHandler >>> {"seq":2,"type":"event","event":"break","body":{"invocationText":"DebugUserRequest(doc=#<Object>)","sourceLine":1,"sourceColumn":4,"sourceLineText":" >>> if (doc.type === \"json\") >>> {","script":{"id":33,"name":null,"lineOffset":0,"columnOffset":0,"lineCount":6},"breakpoints":[1]}} >>> 10 debugger.ccTestClearBreakPoints208 >>> >>> <Execution stuck beyond this point> >>> >>> Line 1-2,4, 5 - basically setup breakpoint and lists them >>> Line 3,6,7-9 - trying to call the user supplied JS code but it doesn’t >>> proceed to finish execution because it’s waiting at the breakpoint set >>> earlier - hoping someone would fire continue/clearbreakpoint >>> Line 10 - Attempt to clear breakpoint but this guy can’t proceed further >>> because the user supplied code(currently stuck at breakpoint) is holding >>> the lock to the isolate >>> >>> So my question is, how can the user supplied code execution could proceed >>> further in this case? >> >> I think I understand what you mean. It sounds like you should be >> using v8::Debug::SendCommand() from the second thread, > > Basically I’m trying to provide an IDE support for JS in the bundled product, > so IDE would never know when “clearbreakpoint" or “continue” request is going > to come. So when a “setbreakpoint” command is fired, I need to point the > MessageHandler, SendCommand and ProcessDebugMessage & finally give up the > Locker. I can’t hold up Locker from second thread(which I assume you referred > to set_break_point thread). Please correct me if my assumption is wrong. > > >> without >> grabbing the Locker or changing the debug listener first. > > Till now, I’ve been doing hit and trail for different combinations to avoid > Locker - but I’ve never been able to run various debug command request > handler without grabbing Locker. But I see v8 test-debug.cc in all places is > testing debug apis without using Locker at all. Sorry I don’t know how to run > handler code without grabbing Locker, when you’ve some time could you please > comment on gist on what possibly I’m missing? > > About “changing the debug listener first” - I didn’t get what you mean. Could > you give hints on what specific changes you meant? > > Given you mentioned 3 different approaches that could help solve my current > issue(based on whatever explanation I was able to relay), I’m hoping one of > them would apply to my use case.
In your gist, you call v8::Debug::SetMessageHandler() in a couple of places. I'd change that to once at start-up so you don't need to grab the Locker when you want to send a message - you don't need it for v8::Debug::SendCommand(). -- -- 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/d/optout.
