Mailing List Archive: a case for vmod VARARGS

a case for vmod VARARGS

Nov 9, 2019, 4:34 AM

Post #1 of 3 (825 views)

Hi,

I would just like to mention that we are working on a vdp/vfp to exec arbitrary
external filter programs. Before you shout "it's unsafe" or "performance will
suck": Yes, you are right, and I totally agree, but we got very good reasons:
The application is extremely low traffic, the filter is quite costly (in the
order of seconds per invocation) and we will highly benefit from address space
isolation (due to a high number of 3rd party libraries used by the filter we are
going to use, so we are convinced that it will leak memory and contain wild
pointers).

That said, we would like to support a syntax similar to

myvdp.set_args("some", "argument", " and more ",
blob.encode(HEX, whatever.get()));

for which we could abuse STRING_LIST or some (bound) list of optional/default
value arguments right now, but actually real VARARGS would be much better/cleaner.

Could we extend the .vmod interface by something like

$Function VOID foo (STRING, ...)

which would turn into a va_args argument of the previous type?

Nils

Re: a case for vmod VARARGS [ In reply to ]

geoff at uplex

Nov 9, 2019, 8:02 AM

Post #2 of 3 (825 views)

Permalink

On 11/9/19 13:34, Nils Goroll wrote:
>
> Could we extend the .vmod interface by something like
>
> $Function VOID foo (STRING, ...)
>
> which would turn into a va_args argument of the previous type?

It's worth pointing out that the variable arg syntax in the VMOD
function call is one thing, and the way it gets handed off the C
function implementing is another. There are some choices.

A function call as above could be seen in C as varargs. But if it's
STRING, the C function could see the args as STRANDS. That would be
almost perfect for our external exec/pipe filter use case, because the
array of strings can be handed off the one of the "v" forms of the
exec() family (it just needs the NULL member on the end).

We don't have something like STRANDS for foo(INT,...) etc, but a general
solution could be for the VMOD varags of type T to be translated to an
array of T in C.

That wouldn't work if you want to have differing data types in the
vararg list. But it seems to me that if you know the types in advance,
you could just declare them explicitly.

VMOD varags as C varargs would work well if you intend to hand off the
args to a C function that takes a va_list parameter (something like
vfprintf). Maybe a good option would be to declare in VCC whether you
want the VMOD varargs to become C varags or an array of TYPE.

So IMO +1 to vararg syntax in VMOD declarations, and consider the
options for translating the varargs to C.

Best,
Geoff
--
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753

http://uplex.de

Re: a case for vmod VARARGS [ In reply to ]

slink at schokola

Nov 10, 2019, 5:37 AM

Post #3 of 3 (825 views)

Permalink

On 09/11/2019 17:02, Geoff Simmons wrote:
> So IMO +1 to vararg syntax in VMOD declarations, and consider the
> options for translating the varargs to C.

I agree and I did not intend to imply that we needed to use C varargs. An arrays
appears to be a good option.

Also I think that restricting varargs to be of a single type should be fine,
because we already got optional arguments and default values.

Nils

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Mailing List Archive

Mailing List Archive

Attached Files: