| … | |
… | |
| 603 | Their lifetime, simplified, looks like this: when they are empty, they |
603 | Their lifetime, simplified, looks like this: when they are empty, they |
| 604 | will finish very quickly. If they contain only requests that are in the |
604 | will finish very quickly. If they contain only requests that are in the |
| 605 | C<done> state, they will also finish. Otherwise they will continue to |
605 | C<done> state, they will also finish. Otherwise they will continue to |
| 606 | exist. |
606 | exist. |
| 607 | |
607 | |
|
|
608 | That means after creating a group you have some time to add requests. And |
|
|
609 | in the callbacks of those requests, you can add further requests to the |
|
|
610 | group. And only when all those requests have finished will the the group |
|
|
611 | itself finish. |
|
|
612 | |
| 608 | =over 4 |
613 | =over 4 |
| 609 | |
614 | |
| 610 | =item $grp->add (...) |
615 | =item $grp->add (...) |
| 611 | |
616 | |
| 612 | =item add $grp ... |
617 | =item add $grp ... |
| 613 | |
618 | |
| 614 | Add one or more |
619 | Add one or more requests to the group. Any type of L<IO::AIO::REQ> can |
| 615 | Cancels the request, if possible. Has the effect of skipping execution |
620 | be added, including other groups, as long as you do not create circular |
| 616 | when entering the B<execute> state and skipping calling the callback when |
621 | dependencies. |
| 617 | entering the the B<result> state, but will leave the request otherwise |
622 | |
| 618 | untouched. That means that requests that currently execute will not be |
623 | Returns all its arguments. |
| 619 | stopped and resources held by the request will not be freed prematurely. |
|
|
| 620 | |
624 | |
| 621 | =back |
625 | =back |
| 622 | |
626 | |
| 623 | =head2 SUPPORT FUNCTIONS |
627 | =head2 SUPPORT FUNCTIONS |
| 624 | |
628 | |
