Mirror of forum.nim-lang.org

8163 :: "No handles or timers registered in dispatcher" in Chapter 3.17 example of Nim In Action

• geohuz (orginal) [2021-06-27T15:30:11+02:00] view original

  I'm learning nim async programming by reading the book "Nim In Action", and here is the example code of 3.17:

  
  import asyncdispatch, asyncfile
  
  var file = openAsync("/etc/passwd")
  let dataFut = file.readAll()
  dataFut.callback =
    proc (future: Future[string]) =
      echo(future.read())
  
  asyncdispatch.runForever()
  Run

  but I get "No handles or timers registered in dispatcher" error on the compiler. How can I fix it?

---

• dom96 (orginal) [2021-06-27T16:49:06+02:00] view original

  You can just do this:

  import asyncdispatch, asyncfile
  
  var file = openAsync("/etc/passwd")
  let dataFut = file.readAll()
  
  echo waitFor(dataFut)
  Run

  or

  import asyncdispatch, asyncfile
  
  var file = openAsync("/etc/passwd")
  let dataFut = file.readAll()
  dataFut.callback =
    proc (future: Future[string]) =
      echo(future.read())
  
  
  while asyncdispatch.hasPendingOperations():
    asyncdispatch.poll()
  Run

---

• QMaster (orginal) [2021-06-27T17:11:45+02:00] view original

  @dom Isn't it a good reason to put

  
  while asyncdispatch.hasPendingOperations():
    asyncdispatch.poll()
  Run

  into runForever or waitFor?

---

• dom96 (orginal) [2021-06-27T19:20:11+02:00] view original

  Nope, runForever is meant to be used for server-applications that need to truly run forever. So an error is better.

---

• QMaster (orginal) [2021-07-19T21:08:30+02:00] view original

  It is a bad error making no sense at all for async environments. Just if you have any pending callbacks, but no timers and socket handlers it'll fail for no reason for good and completely working code. I was into that problem and shown you some examples why this is not good at all. And you advised me to make some dummy timer which is doing nothing to avoid that exception. Seems nothing changed since then, but you promised to look at this problem.

---

• dom96 (orginal) [2021-07-20T12:34:00+02:00] view original

  Where did I advise that? I don't have strong opinions here, but the error is there for a reason: when the event loop has nothing to do all it can do is busy loop (which would result in 100% CPU usage), an error seems better in that case but I'm open to suggestions.

---

• QMaster (orginal) [2021-09-17T14:03:34+02:00] view original

  You've advised me to do so in my bug report somewhere.

  I don't really understand why there should be a 100% CPU usage while waiting for callbacks to fire? Neither asyncio python, nor even 2.7's twisted and tornado main loops never caused 100% cpu usage when waiting for callbacks.

  We're awaiting for some future, which might be somewhere, so main loop is knowing that it has at least 1 waitpoint and then it suddenly fails with exception that we're not running anything... That's weird. Might we register all awaited futures somewhere and remove them from list on fire(complete of failed)? This will avoid throwing an exception while we're awaiting something, but will throw it if there's really no any task pending in main loop.

---