| 1 | RunLoops |
| 2 | -------- |
| 3 | |
| 4 | WebKit needs to be cross-platform. So instead of using `BLooper`s directly like a native application, it uses a generic abstraction: `RunLoop`s. We implement `RunLoop` using our native classes. |
| 5 | |
| 6 | Here's a good summary of what a `RunLoop` does: |
| 7 | |
| 8 | > The job of a RunLoop in WebKit is to receive and perform tasks. A thread with a RunLoop running will do nothing until it receives a piece of work to perform. It will then perform the work and go back to doing nothing. If multiple pieces of work arrive at the same time, RunLoop will queue the work and work on them one at a time. If this sounds like BLoopers, that's because they are! In fact, we use BLoopers to implement RunLoops on HaikuWebKit! |
| 9 | > |
| 10 | > ([source](https://www.haiku-os.org/blog/zardshard/2024-08-16_gsoc_2024_porting_webkit2_final_report#3-nothing-is-being-displayed)) |
| 11 | |
| 12 | We implement RunLoops using `BHandler`s. If the thread has an existing `BLooper`, we attach the `BHandler` to that. If it doesn't, we create one. |
| 13 | |
| 14 | **Code:** |
| 15 | * Source/WTF/wtf/haiku/RunLoopHaiku.cpp |
| 16 | |
| 17 | ### What events trigger a RunLoop to run code? |
| 18 | |
| 19 | WebKit always runs code in response to something. Otherwise, it does nothing. |
| 20 | |
| 21 | WebKit's UIProcess shares a looper with the BApplication. Code in the UIProcess therefore is run for one of two reasons: the BApplication called it, or it received a message that it decided to answer itself. |
| 22 | |
| 23 | WebProcess and NetworkProcess each get their own BApplication, and so get their own BLooper. Code only runs there in response to being launched or because of receiving a message. |
| 24 | |
| 25 | Now, WebProcess would like to rerender the WebPage 60 fps. How does it do that? With a timer! After a delay, the timer (BMessageRunner) sends a message to the WebProcess, letting it render everything again. |
| 26 | |
| 27 | IPC |
| 28 | --- |
| 29 | |
| 30 | We use UNIX sockets for IPC. The reason we don't use `BMessenger`s is that the API isn't quite powerful enough (for details, see the thread starting [here](https://discuss.haiku-os.org/t/gsoc-2024-fixing-ipc-in-webkit-haiku-project/15190/3)). `BMessenger`s can be extended to have the capabilities required, but we decided to use UNIX sockets instead because they work and require very little maintenance on our part. When UIProcess launches a process, it will also create a UNIX connection to it (see Source/WebKit/UIProcess/Launcher/ProcessLauncherHaiku.cpp ProcessLauncher::launchProcess). Finally, WebProcess and NetworkProcess establish a connection directly with each other by passing a socket pair between themselves using UIProcess as the intermediary. |
| 31 | |
| 32 | **Code:** |
| 33 | * Source/WebKit/Platform/IPC/unix/ConnectionUnix.cpp |
| 34 | * Source/WebKit/UIProcess/Launcher/ProcessLauncherHaiku.cpp |
| 35 | |
| 36 | **Further reading:** |
| 37 | * [Fixing IPC in WebKit](https://discuss.haiku-os.org/t/gsoc-2024-fixing-ipc-in-webkit-haiku-project/15190) |
| 38 | * [Fixing IPC](https://www.haiku-os.org/blog/zardshard/2024-08-16_gsoc_2024_porting_webkit2_final_report#4-fixing-ipc) |
| 39 | |