BLOBs as iterators / WS_Append
slink at schokola.de
Wed Mar 11 13:29:27 CET 2015
>> - As briefly discussed on the VDD, I think that we should change VMOD BLOBs to
>> be struct objcore *
> No, we certainly should not tie them to objcore. If we make them iterators,
> it will be a general stand alone type of iterator, where implementations can
> iterate over anything they want, including objcores.
Sounds better, yes.
>> - candiates for stringifications should get an additional null byte after the
>> blob end (if they don't have it, stringification would replace the last blob
> This would be an implementation detail in the iterator-implementation,
> ie: the BLOB-iterator for objcores would have a private secret
> agreement with the fetch code to always ensure the NUL is there so it
> can rely on it.
>> - blob2string could just create an obj on the WS
> So this is where it gets interesting.
> The current STRING_LIST is a sort of cheasy iterator which works really
> well when you interpret VCL string concatenation into C source. It is
> relevant question if the same iterator mechanism should be used for
> STRING(_LIST?) and the current vararg based STRING_LIST would merely
> become a convenient VCC implementation of such an iterator.
> I need to ponder the pros and cons of this entire thing.
Also we could keep the varargish interface and add a TXT_LIST. It's cheesy, but
it's cheap - saving the iterator overhead for simple cases.
>> - WS_Copy is useful, but for stringification f-pointer alignment is in the way
>> -> I think we should have WS function variants for unaligned (char *) ptrs.
> Performance wise it is a very good idea to align strings, many optimized
> versions of string functions rely/expect them to be.
I am well aware of the advantages of proper alignment. Remember
Yes, ws allocations should be aligned by default. But we should have a way to
just append to the ws. I'll propose a patch
More information about the varnish-dev