search

atlas-engineer / nyxt

Nyxt - the hacker's browser.
https://nyxt-browser.com/
9.83k stars 411 forks source link

A plan for concurrency? #1684

Open Ambrevar opened 3 years ago

Ambrevar commented 3 years ago

We've had many concurrency issues in the past, and today's fix b665471bb7829f5e0f4092340a037dbfa82b43c2 is only a reminder that as it is, concurrency is going to hit Nyxt users hard for ever, unless we do something about it.

  1. Can we come up with a general purpose design that protects users from concurrency issues?

    At the core, Nyxt must run multiple threads because of the WebKitGTK loop, I believe there is no way to escape it. But we could bury all the concurrency management in an unexported bubble so that the user cannot call functions or code that, possibly indirectly, lock a mutex or similar.

    A popular way to deal with these issue are actors. I've recently tried out https://mdbergmann.github.io/cl-gserver/index.html, it seems really good.

    All this is a bit too general. Does anyone have a more precise idea on how to isolate concurrency patterns in Nyxt?

  2. Much of our concurrency (as with b665471bb7829f5e0f4092340a037dbfa82b43c2) involves data path. So if solving 1. involves too much work and would take too much time for now, we could at least isolate the concurrency patterns in the data-path library.

    Same question as above: any idea how to implement it for Nyxt data-paths?

Ambrevar commented 3 years ago

Addressing this would fix https://github.com/atlas-engineer/nyxt/issues/1546.