[lldb-dev] strange behaviour at lldb cmd line

[Greg Clayton]

> On Jun 19, 2014, at 7:27 PM, Ed Maste <emaste at freebsd.org> wrote:
> 
> Hi Greg,
> 
> As far as I can tell what's happening here is just that
> Process::Resume() completes and the next prompt is emitted (from the
> main-thread?) before the IOHandler gets pushed in another thread.
> 
> Output from "log enable -n lldb process" with an added log printf
> where ::Resume returns:
> 
> step
> main-thread Process::Resume -- locking run lock
> main-thread Process::PrivateResume() m_stop_id = 4, public state:
> stopped private state: stopped
> main-thread Process::SetPrivateState (running)
> main-thread Process thinks the process has resumed.
> internal-state(p Process::ShouldBroadcastEvent (0x80c410480) => new
> state: running, last broadcast state: running - YES
> main-thread Process::PrivateResume() returning
> (lldb) internal-state(p Process::HandlePrivateEvent (pid = 15646)
> broadcasting new state running (old state stopped) to public
> wait4(pid=15646) MonitorChildProcessThreadFunction ::waitpid (pid =
> 15646, &status, options = 0) => pid = -15646, status = 0x0000057f
> (STOPPED), signal = 5, exit_state = 0
> internal-state(p PushIOHandler
> wait4(pid=15646) Process::SetPrivateState (stopped)
> 
> As before, I don't see how we intend to enforce synchronization
> between those two threads.  It looks like my tiny usleep in
> ::PrivateResume delays the next prompt just long enough for the other
> IOHandler to be pushed.

That will do it. It is tough because Process::Resume() might not succeed so we can't always push the ProcessIOHandler.

I need to find a better way to coordinate the pushing of the ProcessIOHandler so it happens from the same thread that initiates the resume. Then we won't have this issue, but I need to carefully do this so it doesn't push it when the process won't be resumed (since it might already be resumed) or in other edge cases.

Other ideas would be to have the Process::Resume() do some synchronization between the current thread and the internal-state thread so it waits for the internal-state thread to get to the running state before it returns from Process::Resume()...

Greg