This is an archive of the discontinued LLVM Phabricator instance.

Don't call the Process::SyncIOHandler in Target::Launch
ClosedPublic

Authored by ki.stfu on Apr 30 2015, 7:13 AM.

Details

Summary

This patch moves synchronization of iohandler to CommandObjectProcessLaunch::DoExecute like it was done in CommandObjectProcessContinue::DoExecute.

Diff Detail

Event Timeline

ki.stfu updated this revision to Diff 24705.Apr 30 2015, 7:13 AM
ki.stfu retitled this revision from to Don't call the Process::SyncIOHandler in Target::Launch.
ki.stfu updated this object.
ki.stfu edited the test plan for this revision. (Show Details)
ki.stfu added reviewers: jingham, clayborg.
ki.stfu added subscribers: jingham, clayborg, Unknown Object (MLST).

Friendly ping.

clayborg accepted this revision.May 5 2015, 10:49 AM
clayborg edited edge metadata.

Looks good.

This revision is now accepted and ready to land.May 5 2015, 10:49 AM
ki.stfu closed this revision.May 6 2015, 11:29 PM
labath added a subscriber: labath.May 7 2015, 6:40 AM

Is change this necessary to ensure correctness, or is it just a matter of saving some lines of code?

I am asking this because, this change has increased the running time of the test suite (compare http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/2252 with http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/2251), sending TestConcurrentEvents over the 5m limit on the linux build bot. It's not clear to me why is this the case, but the test takes ~6 minutes now, where previously it took slightly less than 5. For now I have increased the timeout limit to address this, but we will need to do something different in the future.

My IOHandler patch will eventually fix this, but for now any calls to process_sp->SyncIOHandler(2000) end up causing me to sleep for 2 seconds since the SyncIOHandler is essentially a sleep(2) as it is not doing what the original author intended it to do. This could be fixed in a separate patch until we can truly get this fixed. The issue with SyncIOHandler() is it does:

m_iohandler_sync.WaitForValueEqualTo(true, &timeout, &timed_out);

where "timeout" is set to 2000 ms...

But the problem with quick continues where you hit a breakpoint right away is there is code that does:

void
Process::HandlePrivateEvent (EventSP &event_sp)
{
    ....
    if (StateIsRunningState (new_state))
    {
        ....
        m_iohandler_sync.SetValue(true, eBroadcastAlways);
    }
    else if (StateIsStoppedState(new_state, false))
    {
        m_iohandler_sync.SetValue(false, eBroadcastNever);
    }
    ....

So a quick run will set m_iohandler_sync to true, then false. Then whomever calls process_sp->SyncIOHandler(...) will block for 2000 ms since m_iohandler_sync is set to true, then false again. So you could basically just replace all m_iohandler_sync.SetValue(2000) calls with sleep(2) and you would get the same behavior as what we currently have. This is what I was trying to fix with my IOHandler patches, but they didn't work for everyone. We really need the linux folks and others to help improve my IOHandler patch that removes the SyncIOHandler() and coordinates async output with the top IOHandler to truly fix this.

RE: Is change this necessary to ensure correctness, or is it just a matter

of saving some lines of code?
It was done to ensure correctness because Target::Launch consists of ~4
branches of code where it was needed and it was to difficult to maintain.
In addition it is needed only for lldb to ensure that event is handled
before printing of (lldb) prompt, but if it doesn't matter when we using a
public API (i.e. SBTarget::Launch).
And the last benefit is to remove the duplicated code.

RE: It's not clear to me why is this the case, but the test takes ~6

minutes now, where previously it took slightly less than 5.
I think it is a matter of TestMiStartupOptoins failure because each test is
waiting ~30sec before failing.

Thanks,
Ilia