-
Notifications
You must be signed in to change notification settings - Fork 4
Conversation
Fix some warnings at rlpx.nim. Commented debug echo in rlpx.nim.
@zah openarray[T] is not supported in closure iterators (it can't be compiled) and also even where it possible to use, its not possible to check if this openarray[T] in stack or not. I wish not to use |
Let's get to the bottom of the
|
Btw, Nim can trivially expose a helper allowing one to check if something is on the stack or not. This will be a simple address range check, because Nim needs to store the boundaries of the stack anyway for the purpose of scanning it for GC roots. |
Imo async function just can't take an openarray in general because the function execution can outlive the passed value no matter if it's stack or heap backed. Thus using openarrays in async proc signatures directly is not an option as i'm seeing it, because an async proc can always be called not only with proc foo(a: openarray[int]) {.async.} = ...
# Will be actually translated to
proc foo(a: ptr int, eLen: int): Future[void] = ... And all the |
@yglukhov, what do you think about my proposal for enforcing "structural control flow" in the async procs? If you haven't already, please also read the article linked in the abstract which is explaining the rationale in a much better detail. I've also expanded the proposal with additional support for spawning async tasks from parallel blocks, so @cheatfate please take a look at that part too. If we adopt this "structural" model, then |
@zah structural control flow do not solve this problem, article you mentioned just trying to move out from |
But if compiler allow us to check if openarray[T] is from stack, then we can make a local copy in closure environment (in heap). |
My proposal does solve the problem. Show me an example that you think doesn't work and I'll explain in detail why it works (under enforced awaits). My impression is that you still haven't read the article, because you keep making wrong characterisations of it. It doesn't "try to move from goto to go". It compares the non-structural approaches to asynchronicity to |
@zah, well enforcing structural control flow might work, in the same way as my suggestion about making async/await transformations more powerful so that they would allow using |
I think my RFC is the right place to discuss this further, we shouldn't hold this pull request as a hostage :) It looks good to me for merging. But it does highlight the benefits of the ideas in the RFC and I hope @cheatfate will finally see them as well. Without enforcing the structural control flow, the proposed |
@zah, i have read your article and also i have watched source code of There is bunch of callbacks used in asyncdispatch:
Trio uses much less types of callbacks, but it still uses it to transfer control flow. You can't put kqueue/epoll/iocp to every asynchronous procedure to avoid callbacks. Also you can't remove callSoon callbacks. All other its just syntax sugar. |
@cheatfate, there are two separate topics that we have discussed so far:
Footnotes:[1] I'll clarify the point on Rust, because it may be a bit tricky: Again, right now I really care about the high-level user interface and my RFC is only about that. The internals are a relatively orthogonal topic as far as I can tell (the internals can affect the semantics of the high-level interface, but I think we all agree that async should be done with resumable functions in Nim). |
Move nim-eth-p2p to use asyncdispatch2.
Fix some warnings and debug echoes in rlpx.nim.