I'm heading out now so I didn't read this in detail, I'll do so tomorrow, but I just want to clarify this one point.
It is not true that processes have one state. They have two, a public state, and a private state. When you do a user level "step-over" for instance, you are actually single-stepping the process multiple times get through the range (plus stepping in, running back out again, calling functions to figure out how to step through trampolines, etc...) So for many cases where to the outside world the process looks like it has just "been running" it has in fact stopped and started many times. It is important that these private state changes not leak out to people who are waiting on state changed events at the Process level. The whole logic of the execution control depends on this distinction being carefully maintained. That's why the notion of a "private run lock" and a "public run lock" seemed like a reasonable solution, since they mirror this basic construct within lldb's execution engine. Jim On Apr 18, 2013, at 7:17 PM, "Malea, Daniel" <[email protected]> wrote: > Sorry I was not too clear -- basically I'm worried about the complexity of > having two discrete R/W locks here, and separate behaviour based on > internal/external threads. Since processes have one state, it "feels" like > there should be one lock. > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
