-
Nils Goroll authored
VDP_END marks the end of successful processing, it is issued by VDP_DeliverObj() and may also be sent downstream by processors ending the stream (for return value != 0) VDP_END must at most be generated once per processor, so any VDP sending it downstream must itself not forward it a second time. * VDP_bytes() The only relevant change is the assertion that VDP_END must not be received by any VDP more than once. This comes with minor restructuring of the handling of the three actions * VDP_DeliverObj() Here, VDP_END is pushed down after succesful iteration over the objects. We could also send the last storage segment with VDP_END, but this would require a change in all stevedores. Unless there is a good case for it, I do not see much value in this minor optimization. * ESI: In ved_vdp_esi_bytes we now push down VDP_END whenever we are done with an ESI object at esi_level == 0. ved_bytes() handles the pushes from higher esi levels downwards, so it now changes VDP_END into VDP_FLUSH. We need to remove the additional VDP_FLUSH from ved_deliver because the VDP_END from VDP_DeliverObj() needs to be the last bit sent. The gzgz vdp actually does something which would be impossible for an esi_level == 0 VDP: push bytes from _fini. This could be reworked, but there is also no need to. * range VDP Here we now send the VDP_END with the last segment before the end of the range is it. We also take the opportunity and eleminate null VDP_bytes calls before the range is reached. * rot13 debug VDP Here we need to ensure that we pass on VDP_END