[Lldb-commits] [PATCH] D50912: Don't cancel the current IOHandler when we push the ProcessIO handler.

Jim Ingham via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Fri Aug 17 12:17:50 PDT 2018


jingham added a comment.

It isn't true that the ProcessIO handler will have a short duration, in general.  It will live on the stack as long as process is running, which is of arbitrary duration.   I actually don't think that much matters to this discussion, however.

The most common IOHandler that's going to be on the stack when the Process IO handler is called is the EditLine handler.  That handler's Cancel does two things, one is to lock the output mutex - which is what you are trying to avoid, and one is to fix up the cursor location so that process IO won't mix with command IO, and tell the IO handler it has been interrupted.  When you are interrupting the IOHandler for a hand-called function, especially in the middle of a command, which is what will happen when you are in the middle of completion you actually don't want the cursor to get reset either.  But for a regular continue you probably do want to do all this work.  lldb knows the difference between a "real" continue - when the user expects to give control over to the ProcessIO handler, and a hand-called function (m_running_user_expression gets set in the ProcessModID).  I wonder if there's some way to use that fact to discriminate between the times it's good to avoid cancelling the underlying IO handler and when its not.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50912





More information about the lldb-commits mailing list