Async function execution internals#1355
Conversation
| ch := acs.impl(ctx, acs.argVals...) | ||
| // Wait for the async computation to finish or for the context to be cancelled. | ||
| select { | ||
| case r := <-ch: |
There was a problem hiding this comment.
We should probably check for the channel being nil, or the channel being closed without a value (or the channel itself sends a nil).
|
|
||
| // hashCall computes the composite bucket key for an async call. | ||
| // | ||
| // Only string and bool argument values contribute to the hash. Numeric and more complex types |
There was a problem hiding this comment.
Instead of excluding numbers, wdyt about normalizing tofloat64?
The concern I have is for an expression like [1, 2, ..., 1000].map(x, asyncFn(x)), everything gets hashed into the same bucket, and it's a O(N^2) pass given that findInBucket is a linear scan.
Ideally, we should handle things like numbers beyond 53 bit mantissa, lists/maps too, but those are rare enough that we could likely defer.
| if err != nil { | ||
| t.Fatalf("NewExecutionFrame() failed: %v", err) | ||
| } | ||
| defer frame.Close() |
There was a problem hiding this comment.
nit: this is unlikely, but perhaps consider adding a simple guard for double close in ExecutionFrame's Close() function (something like if.Activation == nil { return } should make it idempotent)
| function string | ||
| overload string | ||
| args []InterpretableV2 | ||
| impl functions.AsyncOp |
There was a problem hiding this comment.
Question: what happens if the user provided implementation panics? Do we ordinarily recover gracefully?
2 participants
Internal support for async function evaluation.
context.Contextobject and expected to blockuntil a result is available and return it. The framework manages go routines
The implementation supports minimal call deduplication logic which users
will be able to extend with functionality introduced into later PRs.