Skip to content
← Type System and Casting Interfaces with External Systems →

Concurrency Model

(This document is a placeholder and needs to be populated with details about Dana's approach to concurrency and asynchronous operations.)

Key Aspects to Consider/Cover:

  • Motivation: Why is concurrency needed in Dana? (e.g., non-blocking I/O for resource calls, parallel execution of agent tasks).
  • Model Choice:
  • Async/Await (similar to Python/JS)?
  • Goroutines/Channels (Golang-inspired)?
  • Actor Model?
  • Event-driven architecture?
  • Syntax: How are concurrent operations defined and managed in Dana syntax?
  • State Management: How does concurrency interact with SandboxContext and variable scopes? Ensuring thread-safety or appropriate isolation.
  • Resource Handling: How do concurrent operations interact with Resource capabilities? Non-blocking calls to external APIs.
  • Error Handling: How are errors propagated and handled in concurrent or asynchronous operations? (See also error_handling.md).
  • Synchronization Primitives: If needed, what primitives will be available (e.g., locks, semaphores, channels)?
  • Integration with IPV: Can IPV-enabled functions be called concurrently/asynchronously?
  • Impact on REPL: How does the REPL handle asynchronous results?
  • Current Status: Is concurrency a feature for the initial version or a future enhancement?
  • If future, what are the implications for current design choices?

Self-reflection: Given Dana's use in agents and potential for I/O-bound tasks (calling LLMs, external tools), an async/await model might be a natural fit, but this needs careful consideration against Dana's philosophy of simplicity and determinism where possible.