> On Jun 19, 2014, at 7:27 PM, Ed Maste <ema...@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

_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to