How to help get non_blocking across the finish line?

[hugetim]

With reference to #52, I'd also love to use async server calls in a production-ish app. I could just copy the code, but if I could spend a similar amount of time helping it along to become part of anvil-extras, I'd rather do that.

The thing that strikes me as the most likely obstacle is that the API seems tentative in places. (For example, the docs note how Interval works different from an Anvil Timer component in a way that could trip people up.)

Here are some suggested changes for discussion--but no need to respond to any of these. Rather I presume each of them has already been rejected for good reason. But feel free to adopt or discuss further if any of them do seem helpful:

1. Rename call_server_async to server_call_async to better mirror Anvil's (and kompot's) API.
2. Change Interval so that setting delay=0 stops it (the same as delay=None).
3. Rename Interval's delay attribute to `period'.
4. Rename Timeout to Delay (and rename its attribute delay to period). (With period=0, it should execute without delay.)
5. Rename the clear methods to stop.

Also, more generally, I may not know enough to ask this question intelligibly, but would it be better/possible to implement async stuff in Skulpt directly, like using the async/await keywords? (Really, my level of understanding on this is just, "I hear people in Python podcasts talking about async/await, so maybe that's relevant.") In other words, to implement the relevant Python syntax/standard library rather than adding a new package? But I guess that may not be ideal because of some differences between JS and Python that I don't fully understand?

Another way I might be able to contribute is trying to add cases to the existing tests? Would that be helpful?

[s-cork]

Re skulpt. Unfortunately I think that'll take a long time.

My main problem with async await in Python for anvil is that you always have to block somewhere to run the event loop. Async calls then do their thing. But I've never seen async code that gives a callback and says 'give me the result when you're done, and I'll continue doing stuff until then'.

It's more 'give me the result when you're done and I guess I'll just wait patiently until then'.

I'd love to see an example of the former. But that seems to be more of a threading pattern.

The tasks in the event loop are free to hand over to each other while they await. But you always seem to have to wait for all tasks to complete before moving on in your code.

So I've never quite gotten my head around how it would look in Anvil. I haven't done that much serious python async await stuff though.

---

I was never fully happy with the API so I'll have a think about your suggestions. I was quite influenced by the JavaScript api. I did think about delay=0.

@meatballs did you use either of these in your code yet?

How do we feel about the rest of the API?

[meatballs]

I do find the current api tricky - it's fine to use but when I come back to the code later, it's not immediately obvious how it works.

I like the idea of wrapping the js api but with changed terms. repeat sounds great, but I'm not sold on delay. How about defer instead?

[s-cork]

yeah I could get behind defer

[hugetim]

Actually, I kind of like just keeping the JavaScript terms now that I understand where they come from. If the API is going to closely parallel the JavaScript, it might be helpful to keep the names the same as well. But I'm fine either way. (Regardless, no need to worry about set_interval(some_func, 0) behaving differently from an Anvil Timer with interval 0 anymore.)

[s-cork]

that's a 🔧

We currently have

from anvil_labs import non_blocking

i = 0
def do_heartbeat():
    global heartbeat_ref, i
    if i >= 42:
        heartbeat_ref.cancel()
    print("da dum")
    i += 1

heartbeat_ref = non_blocking.repeat(do_heartbeat, 1)

We could also have the same code but with the last line as:

heartbeat_ref = non_blocking.set_interval(do_heartbeat, 1)

I worry that the javascript API is fine if you know its origins.
But if you don't it's not that obvious.
Hard for me to see it with fresh eyes though 👀

Worth noting that anyone can always just roll your own version

from anvil.js.window import setInterval
ref = setInterval(fn, 1000)

[hugetim]

Yeah, if the JavaScript setInterval is that easily accessible, maybe it's better to just direct people to that for these functions rather than create thin Python wrappers?

On balance, I do like the repeat and defer non_blocking functions, though. They will be appreciated by people like me coming without that JavaScript background. (Apologies for the indecision.)

[hugetim]

@s-cork from the other comment thread:

When we do anvil.server.call() it's more like await anvil.server.call()
Other code can execute while the call is happening since control of the event loop can be given to other tasks.

Whoa, this is not what I expected. So that means a Timer tick event could fire (and execute client code) while a server function is running?

But user input via the UI is blocked during a server call (even call_s), right?

[s-cork]

And Timer - yeah they're are just glorified setTimeout calls that reset the timeout to the current .interval value after each call
So a timer tick event can also execute during a server call

You can see in the source code for the Timer
https://github.com/anvil-works/anvil-runtime/blob/89b6d15bc5a1bd2bc9aee4938abd3bbf26b6e0ec/client/js/components/Timer.js#L74-L85

[hugetim]

Ok, I see. Thanks!
But the server is strictly serial, right? Even when used with call_async, server calls are going to be queued on the server in the order they were called and run one-after-the-other.

[s-cork]

yes that's right - they will execute in the order they are called.
And one server call won't run until the previous one has finished.

[hugetim]

Also, is there some other reason why a button would sometimes not register a click? I thought that had happened to me sometimes, and I attributed it to a Timer running a server.call_s, but maybe I was just imagining things (and just hadn't fully pressed down the mouse button or something).

[s-cork]

not that I know of

[hugetim]

(In reference to: #70 (reply in thread)) Ok, I think what must have happened is that I was expecting the button to trigger a server call with the spinner. But the silent server call was still running. So the button click function ran, but it stopped at the "await server.call" line until the silent server call was finished. If that's right (I won't be able to test it for a bit), I may make an Anvil feature request to start the spinner right away, even if the server call hasn't started (been sent?) yet due to a backup in the server queue.

…

On Wed, Apr 27, 2022, 8:37 AM stu ***@***.***> wrote: not that I know of — Reply to this email directly, view it on GitHub <#70 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB63GLAFAQOHDPCR5XWJSPDVHE7H3ANCNFSM5UMMGUDQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[s-cork]

Ah yes I could how that might happen.

A repo app and a forum post will be the way to go 👍

[hugetim]

Nope, I was wrong. The spinner starts right away, even if there's already a silent server call running.

[hugetim]

For what it's worth, now that I understand that ordinary call_s server calls do not stop other client code from functioning (with the only exception being code directly following the call_s in the specific function it is a part of), I don't currently have a use for the functionality provided by the NonBlocking module.