Awaiting for Future[void] fails if future never completes or fails

[Q-Master]

When trying to wait for the guard future I've encountered a wrong behaviour, IMHO. The idea is to wait some arbitrary future, which might be completed from some outer code not depending on guarded async code completed or not.

This code

import asyncdispatch

var guardfuture = newFuture[void]("test.guardfuture")

proc a() {.async.} =
    await sleepAsync(1000)

proc b() {.async.} =
    var af: auto = a()
    await guardfuture
    await af

proc fireGuard() =
    guardfuture.complete()

proc testGuard() {.async.} =
    await b()

proc stop() {.noconv.} =
    fireGuard()

when isMainModule:
    setControlCHook(stop)
    waitFor testGuard()
    quit(QuitSuccess)

should wait forever till ctrl+C pressed, but it fails just after proc a completes, with a message

/usr/local/Cellar/nim/1.2.0/nim/lib/pure/asyncdispatch.nim(1886) waitFor
/usr/local/Cellar/nim/1.2.0/nim/lib/pure/asyncdispatch.nim(1576) poll
/usr/local/Cellar/nim/1.2.0/nim/lib/pure/asyncdispatch.nim(1291) runOnce
Error: unhandled exception: No handles or timers registered in dispatcher. [ValueError]

but if I comment out awaiting the guardfuture in proc a, everything works without errors, but not as expected and quits just after a() completes.

If I press ctrl+c while timer is ticking, everything also works as a charm.

$ nim -v
Nim Compiler Version 1.2.0 [MacOSX: amd64]

The latest build from source has the same issue.

$ ./bin/nim -v
Nim Compiler Version 1.3.5 [MacOSX: amd64]

[dom96]

Might be about time we just make the event loop call sleep if it has nothing else to do. If you want a workaround add a dummy timer using addTimer.

[Q-Master]

Adding dummy timer helped, thanks. But anyways this is a weird workaround, so waiting for sleep implementation.

[dom96]

Most apps will be doing some actual IO work, if you're not then there is no reason to use async await. So in real applications you shouldn't need that workaround.

I wouldn't hold my breath on a fix here.

[Q-Master]

As I wrote in example you definitely not know if guarded async task finished or not, but the code should wait for some event.
The code should not fail with exception if the main loop has no more tasks to do. It might happen that there's some sync code without IO working in the background, and will produce the event which restarts the async part of the code.

[Araq]

@dom96 I think this should work and not everybody uses async only for IO, a task system is generally useful. Is it hard to fix/change?

[dom96]

Like I said, I guess we can just add a sleep in this case. But I haven't thought hard about it.

[capocasa]

Just got bit by this- understandable as an 80/20 rule thing but definitely causes adoption friction

[dom96]

Definitely and I'd love for this to be fixed.

Some questions:

• How do other async/await implementations deal with this?
• Are you interested in prototyping a fix for this?

[capocasa]

I don't know, I'd have to learn a great deal about python implementation details from scratch to find the relevant code.

The best I can do right now is share my hunch that this is one of those situations where the best available solution is to accept that we are going to create a wart. I suspect python did that too because they had to find a solution within the same constraints. Like you said- why do async without i/o? If you're not waiting for an i/o, you by definition have everything you need to continue, so don't await anything, just run the code now.

After a fair bit of trying, the only use-case for async without I/O I could come up with is a dummy program to learn more about how async behaves.

Therefore, I'm fairly confident it would be okay to scrap the error message and create a dummy timer in its place. That's pretty darn ugly, but that's okay, because it's only ever going to be in people's learning code.

[dom96]

I don't know, I'd have to learn a great deal about python implementation details from scratch to find the relevant code.

Not necessarily. I just mean: does Python also exit with an error? Does it spinlock the CPU up to 100%? or does it just work (TM)?

[capocasa]

Oh, okay- yeah in Python it just works, the reproduction code for this issue is literally python's Hello World example.

Not sure what your frame of reference here is, if by prototyping you mean describing desired behavior- Yeah I think this should just work in Nim too.

# Python

# this works
import asyncio

async def main():
    print('Hello ...')
    await asyncio.sleep(1)
    print('... World!')

asyncio.run(main())

# Nim

# this errors out with "No handles or timers registered in dispatcher."
import asyncdispatch

proc foo() {.async.} =
  await sleepAsync(1000)
  echo "foo done"

asyncCheck (foo())
runForever()

[dom96]

Those examples aren't equivalent though, asyncio.run is equivalent to Nim's waitFor:

import asyncdispatch

proc foo() {.async.} =
  await sleepAsync(1000)
  echo "foo done"

waitFor foo() # This shouldn't fail

or maybe I'm wrong and asyncio.run will actually run forever?

[capocasa]

Yeah, you're right! Here's the actual equivalent:

# Python

import asyncio

async def main():
    print('Hello ...')
    await asyncio.sleep(1)
    print('... World!')
    # await asyncio.start_server(lambda r, w : nil, 'localhost', 9999)

asyncio.ensure_future(main())
asyncio.get_event_loop().run_forever()

Doesn't seem to make any difference, works fine.

I got the idea to trace the system calls instead of code digging in the python sources- if I interpret the linuxese correctly, python does stuff on a nonexistant dummy, or perhaps something like stdio?

strace python r14564.py

newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=39502, ...}, AT_EMPTY_PATH) = 0
read(3, "\"\"\"Event loop using a selector a"..., 39503) = 39502
read(3, "", 1)                          = 0
close(3)                                = 0
mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f136bb78000
epoll_create1(EPOLL_CLOEXEC)            = 3
socketpair(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0, [4, 5]) = 0
getsockname(4, {sa_family=AF_UNIX}, [128 => 2]) = 0
getsockname(5, {sa_family=AF_UNIX}, [128 => 2]) = 0
ioctl(4, FIONBIO, [1])                  = 0
ioctl(5, FIONBIO, [1])                  = 0
epoll_ctl(3, EPOLL_CTL_ADD, 4, {events=EPOLLIN, data={u32=4, u64=139719581106180}}) = 0
getpid()                                = 20533
epoll_wait(3, [], 1, 0)                 = 0
write(1, "Hello ...\n", 10Hello ...
)             = 10
getpid()                                = 20533
epoll_wait(3, [], 1, 1000)              = 0
epoll_wait(3, [], 1, 0)                 = 0
write(1, "... World!\n", 11... World!
)

However, if the line containing asyncio.start_server is uncommented, you get this portion of system calls:

getsockname(4, {sa_family=AF_UNIX}, [128 => 2]) = 0
getsockname(5, {sa_family=AF_UNIX}, [128 => 2]) = 0
ioctl(4, FIONBIO, [1])                  = 0
ioctl(5, FIONBIO, [1])                  = 0
epoll_ctl(3, EPOLL_CTL_ADD, 4, {events=EPOLLIN, data={u32=4, u64=139968689209348}}) = 0

So although the details are murky to me, it seems clear that python created special code for the no-io case to ensure it Just Works (tm), apparently by opening some kind of dummy file to work on.

In my humble opinion, it doesn't really matter how Nim solves it internally, as long as it Just Works (tm) as well. Since all solutions I can think of have rely on special treatment for the edge case, all seem to increase complexity by the same amount to solve the same number of cases (1). There for they are most likely all equally ugly. I'd probably go for adding a dummy timer since it's the first one one you came up with as a workaround. But using some kind of dummy file for the epoll call in the absence of a proper file or socket seems fine as well, possibly more elegant, most likely a lot more work.