… | |
… | |
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 | |