search

zevv / nim-async-issue

1 stars 0 forks source link

Even README has wrong information here. #4

Open cheatfate opened 5 years ago

cheatfate commented 5 years ago

A bit over a year ago a third-party implementation of async I/O called Chronos[1] was created by people who had specific demands on the I/O layer that the Nim std lib could at time not fill.

This people do not have any specific demands on the I/O layer, this people just to want have reliable networking framework, which works as expected and do not have undefined behaviors inside:

Also to merge one of the previous versions (called upcoming) of asyncdispatch.nim it takes almost 1.5 year. So how do you think does asyncdispatch was worse to fork?

Chronos was originally a fork from Nim async library, but has undergone some breaking API changes. Chronos has seen steady development over the last year, diverging more and more from Nim async, but also fixing some of the issues that were in the Nim standard library.

chronos forked only two files from Nim async library, its asyncfutures.nim and asyncmacro.nim. Actual asynchronous event loop asyncloop.nim was implemented from scratch but you still can find some similarities with asyncdispatch.nim.

The only way to evolve and make asynchronous framework more flexible is to break "bad" API. I'm calling it "bad" because in asyncdispatch every possible operation (e.g. read or write) requires 4 syscalls all the time:

  1. Register to system queue.
  2. Wait for system queue.
  3. Perform operation.
  4. Unregister from system queue.

While in chronos this 4 syscalls will happens only in worse case, more often only 2 syscalls will be called:

  1. Wait for system queue.
  2. Perform operation
zevv commented 5 years ago

Thanks for your input cheatfate.

Even README has wrong information here.

This is exactly why I put this up for review before posting this as an RFC - I am trying to put together a complete and correct description of the issue, so there will be no discussion about the correctness or completeness of the RFC itself. I will update with the above info.

zevv commented 5 years ago

Also a small personal note: please understand that I am not taking sides here, and as an outsider I am not in the position to blame anyone or anything. I do recognize the reasons why Chronos diverged from the stdlib, and I am not at all saying this was in any way a bad decision from your or Status' perspective. I also do see that Chronos is more active maintained, solves long standing issues and is likely in good shape compared to the standard lib.

However, I also do see that having two implementations is problematic and cause of confusion for some, and that there is no trivial or obvious way to resolve this. I'm just asking for a chance to have a proper discussion about this to find how we can best help the Nim ecosystem and community on this.