nimforum mirror - Basic Async Questions

Isofruit (orginal) [2023-08-22T16:41:46+02:00] view original

After the other forum post wanting to efficiently execute a proc at a delayed time I figured I might as well start learning a bit more about async. I have a few rather beginner questions concerning async in nim. For now I just want to explore a bit based on the following code-snippet for which I have a couple questions:

import std/[asyncdispatch]

let echoMe: Callback = proc(fd: AsyncFD): bool =
  echo "Me"
  return true

addTimer(100, true, echoMe)
poll()

What is AsyncFD in terms of meaning? (I'm aware it's a distinct int32, but what does that mean?)

Why does a Callback need to return a boolean? What does it mean to return true/false?

Why does the callback above only execute echoMe once? Shouldn't it do that 5 times given that poll lasts 500ms and the "true" parameter of addTimer means it gets repeated?

Does poll basically say "I'll wait for the next 500ms and process any async-events that get thrown during that timeframe, with addTimer being a source of AsyncEvents?"

Is there any way to do this in a way that means I don't have to call poll because the sources I'm skimming through atm make it sound like that would be the task of a runtime to do manage that sort of thing

PMunch (orginal) [2023-08-22T17:25:53+02:00] view original

AsyncFD is an async file descriptor. Doesn't make much sense in this case, but if you're awaiting a file read or a network request this parameter is used.

I believe this is documented somewhere in the async documentation, but essentially it decides whether this callback should be deregistered from the dispatcher or not. Again useful for things like reading a file block by block, or in this case a continuous timer.

Poll runs for 500ms or until something happens. In this case your timer fires and poll completes after 100ms. You need to continue calling poll for it to happen more than once.

Well as I said it will run for a maximum of 500ms, if something happens before then it completes early.

No, you need to tick the loop continuously. A runtime would basically be a system where you call an async main function and then runForever which would hide the fact that you're ticking the loop

Isofruit (orginal) [2023-08-22T18:23:08+02:00] view original

Regarding the answers:

Could you elaborate? In terms of event loop I just have the mental model of a queue that gets polled every N nanoseconds (or miliseconds). I don't have a mental model of where/how "dispatcher", "registering" and "deregistering" fit into that yet.

After some more googling: So basically std/asyncdispatch is in terms of what it's trying to accomplish comparable to status/chronos is comparable to in rust tokio etc.? They're all basically there to help you set up an event-loop that you can poll every N ns/ms ?

Then as a general question:

So basically if I want to have asyncdispatch working continuosly throughout my application and not think about the eventloop, I need to run:

proc runForever*() =
  while true:
    poll()

Given it's a while-true loop, isn't this essentially blocking a thread with polls to a task-queue until a task is in there and then that thread works on that? Is that okay or is that a bad idea?

PMunch (orginal) [2023-08-22T19:14:31+02:00] view original

Don't have time to reply with something more in-depth right now, but for the mental model waybe this article of mine will help: https://peterme.net/asynchronous-programming-in-nim.html. You might've read that already though.

mashingan (orginal) [2023-08-22T19:39:04+02:00] view original

What is AsyncFD in terms of meaning? (I'm aware it's a distinct int32, but what does that mean?)

FD is abbreviation of file descriptor, on Windows it's called Handle. FD/Handle is basically just and object and with AsyncFD meaning can be applied for asynchronous operation. On Windows it's the Handle that created with Ex variants of IO operations, like ReadFileEx, CreateFileEx etc. On Linux with epoll it's fd that's returned from epoll_create.

Why does a Callback need to return a boolean? What does it mean to return true/false?

Not necessarily but in your specific example, from the doc, addTimer need to return boolean to identify whether it's running once or periodically.

Why does the callback above only execute echoMe once? Shouldn't it do that 5 times given that poll lasts 500ms and the "true" parameter of addTimer means it gets repeated?

poll only waiting "until" 500 ms, if timeout, throw ValueError, since addTimer expired already in 100 ms, so it doesn't need to waste 400 ms. Try changing to runForever() you'll get the uncaught ValueError (idk if this intended or bug).

Is there any way to do this in a way that means I don't have to call poll because the sources I'm skimming through atm make it sound like that would be the task of a runtime to do manage that sort of thing

Directly or indirectly? Indirectly to avoid calling poll, you can just runForever it. To Directly avoiding, you can't because you need to yield the control to another operations/values in queue.

Isofruit (orginal) [2023-08-22T21:51:25+02:00] view original

What's the difference to the prior approach and this?

import std/asyncdispatch

proc afterX(wait: int) {.async.} =
  await sleepAsync(wait)
  echo "Stuff Happened"

waitFor afterX(400)

Are they both basically the same with the waitFor just disguising a poll-loop ?

PMunch (orginal) [2023-08-22T22:55:19+02:00] view original

Pretty much exactly, yes. It's mentioned in the docs here and the implementation is pretty obvious.

Isofruit (orginal) [2023-08-23T08:21:31+02:00] view original

I think I just had somewhat of a lightbulb moment:

Nim has await and waitFor, while JS only has await - which is equivalent to nim's await. JS does not have an equivalent to waitFor.

Is that because in JS basically everything gets executed within an event-loop?

And you just don't notice it/ it gets hidden from you because JS doesn't let you interact with resources outside of the context of an event-loop, so everything you're doing essentially runs within a gargantuan async function within which you can call await as you please ?

Meanwhile whatever code calls an equivalent to waitFor is what's thus running the JS runtime?

PMunch (orginal) [2023-08-23T08:58:58+02:00] view original

Again you're pretty much spot on. In JS and many other languages which implements the async/await pattern the event loop is hidden away from you, run by a part of the runtime for the language. Nim however doesn't really have async/await built in, the language just provides the building blocks, and the rest is supplied in a library.

To answer your questions from earlier:

The async/await system was created in order to deal with slow things like files and network requests. The idea is that if I want to say open a file in my program there is no need to lock my entire program from doing anything else while the kernel spins up the disk and copies the content into memory for me. Instead we can either poll the kernel to tell us when it is done, or we can gather up multiple of these IO operations and then tell the kernel to put our program to sleep until either of them is done. You can do this manually in Nim with the std/selectors module. Async is basically just an abstraction on top of this. When you await some of the low-level IO operations it will simply keep track of the file-descriptor for you, and when you call poll() it will tell the kernel to await the next event (while also adding a 500ms timing event to make sure that it will get it back fairly soon if nothing has happened yet). When poll then gets a reply from the OS that one of the events fired it will look through all the registered callbacks and call the one related to the descriptor that triggered the event. As a slight complication Nim turns all async procedures into closure iterators in order to have a function it can re-enter. Basically {.async.} turns the procedure into a wrapper for a closure iterator, and await turns into some logic to register the file descriptor and a yield statement. When we talk about the async dispatcher it is the system of awaiting file descriptors and running closure iterators we talk about. Registering and deregistering things with the dispatcher is basically just an abstraction around registering and deregistering things for the underlying selector and kernel polling. await will register a callback with the dispatcher, but as you've seen you can also do this yourself.

Pretty much yes, all async systems are pretty similar. Set up an event loop, poll the underlying OS for events, control which callback is run for which event. You seem to be a bit hung of on this notion of running something at specific time intervals though. The async system doesn't do anything unless you call poll() or any of the other things which calls poll(). poll() just takes a timeout for the underlying IO polling to make sure that you can call poll() in a loop with other non-async things. Say for example you have a simple immediate mode UI that you want to keep responsive. You run one loop of the UI code, then call poll() to check for new events, then run another loop of the UI code. Of course you could restructure your UI loop to be a while true: with an await sleepAsync(1) at the end to hand back control to the dispatcher every iteration of the loop.

Mirror of forum.nim-lang.org

10428 :: Basic Async Questions