On 30.04.2014 17:30, Frédéric THOMAS wrote: >> Why to put some BP in on the suspended ones ? > I meant : Why to put some BP only in the suspended ones ? You are right, suspending all running workers that contain the file, setting breakpoint there (and probably resuming?) seems to be the best. Unfortunately some workers may fail to suspend if they are doing nothing. In the latter case breakpoint could be remembered and set when worker gets anything to do. > Also, the compiled FDB attached to the fixed issue is more up to date than > the last one I sent you, I re-applied the mxml BP fix on it. That's what I played with.
Alexander > Frédéric THOMAS > >> From: webdoubl...@hotmail.com >> To: dev@flex.apache.org >> Subject: RE: [FDB] Integration >> Date: Wed, 30 Apr 2014 14:21:45 +0100 >> >>>> I created 2 tickets [1] for the merge, [2] for the fix, I >> attached it the fixed FDB. Main thread with the target file is not >> paused >>> Switching workers when VM is paused after new worker creation seems to >>> work now, that' great! >>> Setting a breakpoint to the file that is not loaded yet and will be >>> loaded later by a new worker also seems to work, that's even more cool! >> >> Yep :-) >> >>> I still see the issue with setting a breakpoint in incorrect file when >>> all workers are loaded but the file belongs to non active one. See [1] >>>> Next steps: >>>> 1- Fix the bad message when a file is not found >>> What do you mean? >> >> It seems I meant just what you said: >>> I still see the issue with setting a breakpoint in incorrect file when >>> all workers are loaded but the file belongs to non active one. See [1] >> >> But I reduced my sentence to the message: >>> Breakpoint 1: file MP3Worker.as, line 30 // WRONG FILE >> >>>> BTW IntelliJ uses only breakpoints, no watches and displays. >> >> I will still need to apply the same logic to each potential command that >> could have the same issue. >> >>> - 'break' command may be called with file name or with file id. If it is >>> called with file id then probably the right thing is to apply the >>> command to the current worker only >> >> Good point, I keep that ! >> >>> - the same file may belong to several workers. So probably fdb should >>> iterate all suspended workers and try to set the breakpoint for all that >>> contain this file. >> >> I would have suspended all workers instead and place a BP in each if it >> belongs to. >> Why to put some BP in on the suspended ones ? >> >>> - new workers that contain this file may appear later. And each existing >>> worker that doesn't contain the file may get new bytecode loaded with >>> this file. So despite of the result of the previous attempts fdb should >>> remember the breakpoint location and try to set it for all new workers >>> that appear later. Also each time when new code is loaded fdb should try >>> to set breakpoint again for each existing worker that didn't contain the >>> file before. >> >> Yep, was my goal too. Cool!
