… | |
… | |
1060 | =item feed $grp $callback->($grp) |
1060 | =item feed $grp $callback->($grp) |
1061 | |
1061 | |
1062 | Sets a feeder/generator on this group: every group can have an attached |
1062 | Sets a feeder/generator on this group: every group can have an attached |
1063 | generator that generates requests if idle. The idea behind this is that, |
1063 | generator that generates requests if idle. The idea behind this is that, |
1064 | although you could just queue as many requests as you want in a group, |
1064 | although you could just queue as many requests as you want in a group, |
1065 | this might starve other requests for a potentially long time. For |
1065 | this might starve other requests for a potentially long time. For example, |
1066 | example, C<aio_scandir> might generate hundreds of thousands C<aio_stat> |
1066 | C<aio_scandir> might generate hundreds of thousands C<aio_stat> requests, |
1067 | requests, delaying any later requests for a long time. |
1067 | delaying any later requests for a long time. |
1068 | |
1068 | |
1069 | To avoid this, and allow incremental generation of requests, you can |
1069 | To avoid this, and allow incremental generation of requests, you can |
1070 | instead a group and set a feeder on it that generates those requests. The |
1070 | instead a group and set a feeder on it that generates those requests. The |
1071 | feed callback will be called whenever there are few enough (see C<limit>, |
1071 | feed callback will be called whenever there are few enough (see C<limit>, |
1072 | below) requests active in the group itself and is expected to queue more |
1072 | below) requests active in the group itself and is expected to queue more |