[WIP]: AsyncChannels[T].

[cheatfate]

• Add AsyncChannel[T] and tests
• Add AsyncThreadEvent and tests.
• Refactor OS API declarations to osapi.nim.
• Add awaitForSingleObject() and awaitForSelectEvent().
• Add skip() to some tests.
• Bump version to 2.2.9.

AsyncChannel[T] now support multiple writer single reader mode. It is also possible to use write/read to/from channel with both synchronous and asynchronous API.

[cheatfate]

Now the only thing which is left is marshalling/unmarshalling of GC objects through channels. Cc @zah.

[mratsim]

I think we should add some tests that we can use Helgrind on (with -d:useMalloc) to make sure we didn't miss any glaring issues: http://valgrind.org/docs/manual/hg-manual.html

[mratsim]

I think a 2-lock Michael Scott Queue is simple enough and proven robust: https://www.cs.rochester.edu/u/scott/papers/1996_PODC_queues.pdf

Note that we don't need the head lock when dequeuing as we are using it in Multi-Producer Single Consumer context.

[cheatfate]

Sorry but proposed algorithm not satisfies AsyncChannel[T] requirement to have both limited/infinite queue size.

[mratsim]

As discussed, it's easily adaptable.

In any case, I do not have a preference for one implementation or the other at this stage, just that we pick one that is simple but robust to start with.

After running the current implementation through helgrind (and adding a script to easily check lock usage correctness), I'm OK with the current implementation.

[jangko]

what is the status of this PR? can I use it for some kind of task scheduler? I'm planning to put it into ETH1 mining simulation along with the upcoming txpool and block finalization.

[mratsim]

Can we rebase this PR and merge it?

Is there something missing? AFAIK @zah you had some idea to improve streaming/serializing?

[zah]

Yes, I've developed enough of the high-level constructs now, so when this is merged it would be less than a day of work to create the final AsyncChannel[T]

[kamilchm]

Is there a plan to move it forward?

[shayanhabibi]

Is there a plan to move it forward?

See the status task runner for a functioning implementation of AsyncChannels (functioning AFAIK) that works for non ref objects. Ref objects will require serialization to something like the ThreadSafeString that's included in the sys module in the same repo. Also includes a functioning AsyncThreadEvent impl (again AFAIK; I have had some odd troubles here and there but nothing exaggerated). Works with chronos 3.0.6 (however one change would have to be made to the PDispatcher type class to export the handles field).

[michaelsbradleyjr]

@shayanhabibi

See the status task runner for a functioning implementation...

Make sure to use the impl/beta2 branch of nim-task-runner to get the latest changes. There's a draft PR https://github.com/status-im/nim-task-runner/pull/11 to merge those changes to that repo's master, but work on the PR stalled. I'll see what I can do to move it forward in the near future.

The nim-status example client makes heavy use of the impl/beta2 branch of nim-task-runner.

[arnetheduck]

Let's take out AsyncThreadEvent from this PR and make it a separate PR - this is the necessary building block to "wake up" chronos after an item has been posted on a queue meaning that the queues themselves do not necessarily have to be part of chronos

[arnetheduck]

https://github.com/status-im/nim-chronos/pull/406 now provides the necessary infrastructure for projects like https://github.com/status-im/nim-taskpools/pulls, https://github.com/status-im/nim-task-runner, QT, etc to integrate with the chronos event loop from their own threads.