| japhb | \o/ | 00:58 | |
| Go patrickb, go patrickb! | |||
| patrickb | I have an architectural question. In the current debugger design, the update cycle strictly follows a pattern: | 07:32 | |
| There is a View class wrapping all of T-W. | 07:33 | ||
| There is a Controller class containing all the domain behavior. | |||
| There is a set of Model classes containing all the current state of the application. | |||
| The Controller is an OO::Actor meaning that all public methods insta-return, returning a promise and are mutually exclusive. | 07:34 | ||
| Events (either from the debug server or T-W) never do much more than calling one of the Controller methods. | 07:35 | ||
| The Controller is the only thing updating the Model. A Controller method typically follows a pattern: | 07:36 | ||
| - Somehow update the model. | 07:37 | ||
| - Call one or more methods on View to trigger a refresh of what's displayed. | |||
| For that purpose the View class has a few methods, to give a few examples: `refresh-threads-view`, `refresh-source`, `refresh-frames`, ... | 07:38 | ||
| To guarantee no race between these update methods and View events, I plan to not call these update methods directly anymore, but have them perform a roundtrip through the event reactor via the newly added interface. | 07:40 | ||
| So far so good. | |||
| Implementing the Locals view via Viewer::Tree now requires me to divert from the above pattern. The Terminal::Widgets::Volatile::Tree::Parent.children() method needs to directly return it's children. So this method needs to call a method on the Controller *and await the returned Promise*. | 07:43 | ||
| This couples the T-W reactor loop to the Controller mutual exclusion which can potentially cause a deadlock should some other event currently have the Controller lock and wait to enter the Views event reactor. | 07:46 | ||
| Rephrased: There is a Controller and a Viewer lock. Up until now locking always locked the Controller first, then the View. The places where the View needed to call the Controller (and thus reversing the lock order) are resolved by the Controller being an Actor, i.e. all methods insta-returning Promises. | 07:49 | ||
| The TWVTP.c() now introduces a lock reversal. It's called from within T-W (thus holding the T-W event reactor lock) and then needs to call a Controller method *and await it's promise* (thus acquires the Controller lock). | 07:51 | ||
| Is there an easy way out? | 07:52 | ||
| Is this solvable at all? | 07:53 | ||
| Would somehow changing the TWVTP.c() possibly help? | |||
| japhb | patrickb: Saw this, but way too tired to figure it out tonight. Will take a look once tomorrow's caffeine intake is sufficient. | 09:28 | |
| patrickb | I start to suspect, it'll be necessary to allow TWVTP.c() to return a Promise. When a promise is returned, the tree is put into a stable temporary state (e.g. by adding a temporary `... loading ...` line below the to be opened parent) and refreshing continues. The promise is `.then`ed on the T-W event reactor. Once the promise succeeds, the tree view first checks if the update is still applicable | ||
| (the parent still exists and is to be expanded) and then updates. | |||
| Oh wow I didn't expect a reply in the next 8 hours or so... | |||
| Sleep well! | |||
| japhb | Just wanted to make sure you knew I was paying attention, even if I couldn't respond cogently yet. | 09:29 | |
| Thanks, see you on the flip side! | |||
| patrickb | o/ | ||
|
10:15
librasteve_ joined
|
|||
| patrickb | It seems TWVT::Node.long-name() is unused. Did it get superceded by TWVT::Parent.id()? | 11:09 | |
|
12:01
Geth left,
Geth joined
13:05
librasteve_ left
15:32
librasteve_ joined
20:15
librasteve_ left
|
|||