Conversation
LeonMatthes
left a comment
There was a problem hiding this comment.
IMO, I think this is going in a good direction, it's a much less invasive change, but allows us to use normal async, which was the goal. 👍
f4a09ae to
965802b
Compare
1827475 to
8a8f9f6
Compare
LeonMatthes
left a comment
There was a problem hiding this comment.
This is going in a good direction. Some nitpicks left.
What I am concerned about most is our continued use of RefCell.
That seems incorrect in an async world (even before this change tbh).
Any ideas how we want to deal with this?
|
@LeonMatthes I agree that |
31df97b to
34f4f41
Compare
f78b2a7 to
f053d13
Compare
LeonMatthes
left a comment
There was a problem hiding this comment.
What I'm most curious about is why not continue using the fine-grained locking on the Context and use a large-scale lock. What is the advantage of that?
Apart from that it's mostly nitpicks left. 👍
a7a03af to
dfaf3e5
Compare
dfaf3e5 to
0fdd100
Compare
Co-authored-by: Leon Matthes <leon.matthes@slint.dev>
…iew doesn't use tokio.
… bunch of RefCells.
… by a lot. Since we're single-threaded anyways, this shouldn't have any negative performance impact.
…ch should fix some deadlocks.
…tifications at that point.
LeonMatthes
left a comment
There was a problem hiding this comment.
Super cool that you managed to get rid of the Rc/RefCell situation all together 👍
As discussed this linearizes all requests at the moment, but as we discussed, that's not necessarily a bad thing, as this was all single-threaded anyhow.
#11131