• Nils Goroll's avatar
    Add VDP_END action for delivery processors · de6288cb
    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
    de6288cb
cache_range.c 7.06 KB