[abdulmajidcse]

Pull Request Checklist

Q	A
Branch?	4.x
Bug fix?	no
New feature?	yes
Deprecations?	no
Issues	#357
License	MIT

Description

Adds an opt-in, Fiber-native TaskGroup API for running named non-blocking operations on the configured React event loop.

• preserves result registration order while tasks execute concurrently
• reports the failed task name and cancels unsettled siblings
• applies one shared deadline and cleans up pending timers/watchers
• inherits the active request execution context
• isolates active groups by execution-context ID
• supports injected LoopInterface implementations
• suspends the parent Fiber when the configured loop is already running, without stopping that loop
• prevents a response from finishing while its request still owns registered child tasks
• documents usage, cleanup callbacks, and blocking-I/O limitations

Closes #357.

Validation

• Docker PHP 8.5: composer test
  • 4,546 tests
  • 17,961 assertions
  • 0 failures or errors
  • 22 PostgreSQL/Redis environment-dependent tests skipped
  • 7 existing PHPUnit notices
• Docker PHP 8.5: composer analyse — no errors
• git diff --check — clean

Checklist

• Tests have been added or updated
• Documentation has been updated if necessary
• Code follows the project coding standards
• All tests pass locally

[techmahedy]

Thanks for the PR

The TaskGroup / Task implementation is clean and well tested. I verified the acceptance criteria from #357 locally: named failures, sibling cancellation, and deterministic deadlines all behave as described.

Decision: deferred to Doppar 5.x

We won't merge this into 4.x, and we'll revisit it for 5.x.

Why

• It is cooperative concurrency, not parallelism. Tasks only overlap while waiting on non-blocking I/O. They run on a single thread.
• The framework's I/O blocks. The DB layer, HTTP client and filesystem calls are blocking, so a group of normal framework calls runs sequentially with no speedup.
• Real concurrency is a large change. It needs some combination of:
  • async drivers (HTTP, MySQL, Redis)
  • promise support in Task::await()
  • a process-backed runner for blocking or CPU-bound work
  • changes to the DB layer
• Public API stability. A new public API in 4.x is hard to change later if the 5.x design differs.

Plan for 5.x

Design the whole concurrency model together: the runner (Fibers and/or processes), the async I/O story, and the TaskGroup API on top. This PR is a good starting point for that design.

If you continue this work for 5.x

Please address these first:

1. Non-Fiber call while the loop is running. It re-enters loop->run(). In testing, a timer callback ran twice, and the nested run stops the outer loop.
2. Any Fiber is treated as "the loop is running". If the loop is not running, a group called from a user Fiber suspends forever and its tasks never start.

Both need a clear error or an explicit option, plus tests.

#357 stays open and moves to the 5.x milestone. Thank you for the contribution.