5

The docs say that

Communication among contracts should be considered as occurring asynchronously.

However, the description of inline communication given is

Inline communication takes the form of requesting other actions that need to be executed as part of the calling action...These can effectively be thought of as nested transactions within the calling transaction

Which seems to be synchronous, so can we not assume synchronous behaviour(result is returned by the function call) for inline actions?

Improve this question

1 Answer 1

Reset to default
4

Yes, both inline actions and deferred actions are asynchronous.

Which seems to be synchronous, so can we not assume synchronous behaviour(result is returned by the function call) for inline actions?

No, inline actions are non-blocking: the inline action is queued to be processed after the action is completed, but it is executed in the same transaction.

For the record, inline actions used to be called "synchronous" at some point in the previous versions, but it was clarified here that the terminology was confusing:

I have adopted the terms "inline" and "deferred" to replace "sync" and "async" in the documentation and API as I feel they are more descriptive of the reality of these transactions

  • for security reasons, I don't think we want to allow the avenue for opaque re-entrancy and/or recursive wasm-vm contexts that would occur if sending a "synchronous" transaction actually processed synchronously. Instead, we would probably queue it for execution immediately after this transaction/call guaranteeing to the contract that this call will complete in its entirety before any foreign code is run. Thus, "inline". I considered "immediate" but worried that it would imply processing before returning execution to the caller.
  • likewise, asynchronous has become an overburdened concept in the modern programming vernacular and is usually associated with some "response" event or callback which we don't have. "deferred" is less burdened and does not currently imply any form of response.
Improve this answer
2
  • Thanks for the answer! If it is how you say it is, the description of inline transactions in the official docs is inaccurate; neither is it executed as part of the calling action nor is it nested. And in fact 'immediate' fits better than 'inline', as 'inline' implies that the line of code calling that action is replaced by the action code. Immediate is at least semantically unambiguous in the sense of how long it takes to return a result, with the only ambiguity being when the action is scheduled. 'Inline' implies it is scheduled at the moment of its call which is unambiguously wrong.
    – Shubhorup Biswas
    Commented Sep 6, 2018 at 4:04
  • 1
    @ShubhorupBiswas i don't see a problem with inline as one if its definitions is constituting an integral part of a continuous sequence of operations or machines which is an accurate description of the process. i agree, however, that the docs could be better, but edit suggestions can be made on the website
    – confused00
    Commented Sep 6, 2018 at 9:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.