> You are right, suspending all running workers that contain the file,
> setting breakpoint there (and probably resuming?) seems to be the best.
Sure resuming it if I halted it.
> 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.
If you have an example of that behavior, give it to me please as I guess in
that case, I can still set the BP, etc.. without the need to halt it or to be
more precise after it failed to halt.
Frédéric THOMAS
> Date: Wed, 30 Apr 2014 19:15:32 +0400
> From: alexander.doros...@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: [FDB] Integration
>
> 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!
