Ah, sorry on re-read, I realize I should have written "inferior" instead of "process" in that paragraph. The private/public state thing makes perfect sense, and I don't think would need to be changed. Private state should not leak out, and might vary many times during the "non-const" / "long-running" operation we're talking about, SB users would only see public state before and after one of these operations long operations.
TL;DR: I'm not sure that a second R/W lock is the right synchronization primitive to use for the internal lock. I think a condition variable in tandem with the first lock is what we are looking for. Cheerio, Dan On 2013-04-18 10:38 PM, "Jim Ingham" <[email protected]> wrote: >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
