event loop

[jaytaph]

i was thinking a bit about adding an event-loop in the system so we can be more flexible with the flow from http stream to screen paint.

I reckon there are eventloop based systems already available, but this would be my take on it. The flow is based on a regular OS scheduler system. There is a queue of work, where the scheduler takes the top of the queue. This is a record with a state and function call to what it should call. The eventloop would loop the tasks in the queue, and every task that is ready, will be executed. Scheduling is non-preemptive (cooperative). A process must yield the work in order for other tasks can run. Some tasks would need to wait upon other tasks (for instance, when we have javascript that we need to execute, the parser should halt, and signal the javascript to run (or basically, add a task to the queue?)

Once the javascript is completed, it will signal the parser to continue. The same setup also works when dealing with empty streams that are waiting for more packets to arrive.

The event loop tasks do NOT take into account any context. If there is context that needs to be saved between to runs of a task, it has to be saved within that task. For instance, the parser can be called from the scheduler. At certain points the parser yields the work, and later on the parser will be called again. It is the parser that should save the information where it was etc.. (basically, we are already doing this in the parser state).

This is the pseudocode:

    while (true) {      
        next_task = task_queue.runnable()
        if next_task == null {
            do_idle_task();
            continue;
        }
        
        response = next_task.func();
        if response.status == status::finished {
            // task does not need to be scheduled again
        }
        
        if response.status == status::yielded {
            task_queue.push(next_task);
        }
    }

A task would look like this:

    func parser() -> TaskResult {
        // nothing in buffer yet. Yield
        if buffer.len() == 0 {
            return TaskResult {
                status: Status::yield;
            }
        }
        
        // eof detected. We can finish this task
        if buffer.closed() {
          return TaskResult {
            status: Status::finished;
        }
        
        while (buffer.len() > 0) {
            do_parse();         
            
            if token == "</script>" {
                // Send a signal that we have javascript waiting for somebody else
                return TaskResult {
                    status: Status::signal,
                    signal: signal::exec_javascript,
                }
            }
        }
        
        // Buffer is starved, so we can yield again. If the buffer was closed because an eof found,
        // the next yield will finish the task.
        return TaskResult {
            status: Status::yield;
        }
    }

Sending a signal allows for tasks to wake up other tasks when needed. This signal must be added to the task when registering:

    scheduler.add_task(javascript_executor(), status: sleep, signals: [exec_javascript]);

This will create a task that will call the javascript executor when the task is running. It will start default in "sleep" mode (not running and skipped on each loop), until it receives a "exec_javascript" signal. At that point the sleep status will become "runnable" state and it will be picked up by the loop.

[jaytaph]

Maybe we should do the execution of a new task a bit different.

Instead of relying on signals, we might be better of doing some kind of other sleep mechanism:

the parser will ask for a new task to be created, and will sleep until that task is done.

Initial setup:

  EvenLoop:
      parser (sleeping)
      javascript executor (sleeping)
      css parser (sleeping)
      tree renderer (sleeping)
      layout renderer (sleeping)
      painter (sleeping)

• Initial there are a few tasks in the queue, but all are sleeping. The eventloop would sit in idle mode.

• Action initiated by the user: load_site("https://www.example.org");

• A task (TSK1) is placed onto the queue that loads the site and is set to status runnable. This task will run and the site will be loaded. It will fetch DNS, connects to the site, and retrieves the given HTML data in a streamed fashion. This means that we have a buffer of data at some point that may or may not be the whole html file. If this is not the case, the data is placed into the parsers input stream. This task will yield until a signal arrives that more data is available (HOW?)

• The parser task (TSK2) wakes up since there is data in the stream. It will ask the tokenizer for tokens. If there are tokens, it will parse this into a tree. When there is no data, but there isn't a EOF token found yet, it means the input stream is exhausted, and we have to wait for new data. This task yield.

• as long as there is no data, no processes are running (maybe some other tasks would be running)

• if there is more data found (signalled how??), TSK1 wakes up and reads more data. This data is fed to the parser input stream and again this task will yield while waiting for more data.

• TSK2 wakes up because there is data in the stream, and continues parsing. It will find a completed <style> block that defines CSS. It will copy the data into the CSS parser stream (do we want to do it like this, or can we start even when we have incomplete data like the regular html stream).

• TSK3 (css parser) wakes up, and creates the tree. Again, when no data is present and not eof, it yields.

• after more data arrived from the network, and the parser is doing its job, it finds that it needs to do javascript. Here we have a few questions. If there is CSS data that still needs to be processed, this must be done first. The reason for this is because we need make sure we have a CSSOM with all data up to this point in the html-stream. This might not be the case because we might had final css data in the stream AND javascript code. So, we must yield until the CSS task is finished.

• Once the css task is finished, the TSK2 (parser) must wake up. It just yielded for CSS to finish, so now it can yield and start the javascript task.

• javascript parsing (TSK4) can now run and do javascript things. It can modify both the DOM and the CSSsom. Once completed, the parser can continue. (could we speed up things here to let the parser continue parsing, and throw away any results in case the javascript writes to the dom and/or css?). This would mean we do javascript processing in another thread.

• Once javascript task has completed, the TSK2 (parser) will run again.

• In the meantime, we can check if there is a dom-tree which we can already process for the tree-rendered. Any modifications in the CSS will obsolete the current tree, AND any modification in the dom BEFORE where we currently are in the rendered-tree will obsolete the tree as well.

• The tree renderer can run when there is nothing else able to run. For instance, when we wait for html-data but we already have things in csssom and dom ready.

The biggest question would be how do we trigger tasks, and wait for certain conditions to arise. We could wake up tasks by signalling them to run for instance)

[jaytaph]

One way of figuring out if there is more data available in the network stack, is to have the loader always on runnable. So every loop it will be executed: it will quickly check if there is already more data available, and if not, it will yield. This is a bit of a polling situation.. but i'm not sure how we can make this a push (only set the task to runnable when there is data.. We could do this though by different threads. In that case, the loader will push more data over a channel and signals the parser task. The loader on the separate thread will do it's own loop (probably a select() call if that's available in rust). This means we don't need to poll so we don't waste any cycles on something that the OS can do better internally..