Locking ContextManager and websocket patching

[mwx23]

I'm just wondering about the mechanics of locking, particularly around the behaviour of the ContextManager.

When the scope has left the with self.lock does that guarantee an update/patch will be sent over the websocket?

Could one do something like the following to use CSS animations perhaps?

with node.lock:
    node.class_list.add('animate_in')
sleep(5)
with node.lock:
    node.class_list.add('animate_out')

Sorry not at computer but just occurred to me.

[fscherf]

@mwx23 Excellent question! No. Locking has nothing to do with sending updates over the websocket, it's a mechanism to avoid race conditions between threads.

Let's say we have a view with a counter that gets increased once a second, and there is a button to decrease the counter. The counter may be never lower than one (code is not tested).

class CounterView(LonaView):
    def handle_button_click(self, input_event):
        with self.html.lock:
            current_value = int(self.html[0].get_text())
            value = current_value - 1

            if value < 0:
                value = 0

            self.html[0].set_text(value)

    def handle_request(self, request):
        self.html = HTML(
            Div(
                '0',
                _id='counter',
            ),
            Button('-', _id='dec', handle_click=self.handle_button_click),
        )

        while True:
            with self.html.lock:
                current_value = int(self.html[0].get_text())
                value = current_value + 1
                self.html[0].set_text(value)

                self.show(self.html)
                self.sleep(1)

First of all: handle_request() and handle_button_click() run in different threads, semi concurrent!

To increase the counter by exactly one, handle_request() has to read the current value first, increase it, and then write it back. While the thread does that, no one may read or write self.html to avoid a race condition between reading and writing. Therefore handle_request() pulls a lock to do so. For handle_button_click() its the same thing.

Every operation on an Lona node pulls a lock implicitly. If handle_button_click() wouldn't pull a lock and run self.html.get_text() or html[0].style['color'] = 'red' directly instead, while the lock in handle_request() still runs, the call would be delayed until handle_request() releases it's lock.
So every operation is thread safe by default, and you can group operations with the context manager.

From handle_request() you have to run self.show() to finally push updates. Event handlers don't have to, because they are short lived, and when they return, Lona checks if the html is patched and runs self.show() implicitly. (self.show() also pulls a lock before serializing the tree and sending it to the client(s) to avoid glitches between the clients)

CSS animations: I wouldn't recommend to control timing sensitive animations from the Lona view directly. The locking mechanism ensures thread safety, but is not timing safe. I would use a frontend widget that uses some js code to control the animations and would use Widget.data to control the code. I can give you a simple example for that if you want