<div dir="ltr"><div>As usual, thanks a bunch for all your help!</div><div><br></div><div>Using the THR_* functions work: <a href="https://github.com/gquintard/vmod_rers/blob/270a2f4272be49f8c1c904b899ec91dafcf2f873/src/lib.rs#L227">https://github.com/gquintard/vmod_rers/blob/270a2f4272be49f8c1c904b899ec91dafcf2f873/src/lib.rs#L227</a> and they allow me to merge most of the vfp/vdp init code together (helped by the fact the same rust structure is both a VDP and a VFP)</div><div><br></div><div>It would be even more legible if we had access to the vrt_ctx directly (for both vfp AND vdp) so I wouldn't have to build my own, OR if we hade VRT_priv_task_raw_parts(const req *, const busyobj *, const void *) so I didn't have to build my own context, but that is already pretty sweet</div><div><br></div><div>Cheers!<br></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br></div><div>Guillaume Quintard<br></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 3, 2022 at 7:58 AM Dridi Boukelmoune <<a href="mailto:dridi@varni.sh">dridi@varni.sh</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Dec 31, 2021 at 11:48 PM Guillaume Quintard<br>
<<a href="mailto:guillaume.quintard@gmail.com" target="_blank">guillaume.quintard@gmail.com</a>> wrote:<br>
><br>
> Small follow-up on that one: it would be nice for VFP to be able to disable streaming (bo->do_stream), so that's an extra argument to be able to access the busyobj<br>
><br>
> --<br>
> Guillaume Quintard<br>
><br>
><br>
> On Sun, Dec 26, 2021 at 6:11 PM Guillaume Quintard <<a href="mailto:guillaume.quintard@gmail.com" target="_blank">guillaume.quintard@gmail.com</a>> wrote:<br>
>><br>
>> Happy holidays to everyone,<br>
<br>
Happy new year !<br>
<br>
>> Unless I'm mistaken, there's no way for a VFP to access the busyobj, and was wondering if that could change as I need it to retrieve a vmod_priv.<br>
<br>
I think your statement is correct.<br>
<br>
>> For some context, I stumbled on this while working on this vmod: <a href="https://github.com/gquintard/vmod_rers/tree/v0.0.2" rel="noreferrer" target="_blank">https://github.com/gquintard/vmod_rers/tree/v0.0.2</a><br>
>> (It's in rust, and I'm using it to explore what kind of bindings we need. I already have a couple of examples for VDP[1] and VFP[2] in the crate[3] repo, but of course they don't need as much as a real vmod.)<br>
>><br>
>> With vmod_rers, the user is able to add regex/sub pairs on a per-request basis [4], and they will be acted upon by the VDP. To store and retrieve the pairs I use the regular "fake vrt_ctx trick"[4], since the VDP has access to the req struct, it's very easy to build.<br>
>> However, I'm unable to do the same thing on the VFP side since I have neither a req (fair) nor a bo.<br>
<br>
The big difference between both is that we only use VDPs to deliver<br>
client responses, but we use VFPs to fetch both beresp and req bodies,<br>
so the VFP operates at the objcore level.<br>
<br>
>> Is there a big reason for not having access to it, or is it just that nobody asked for it until now?<br>
<br>
Probably nobody never asked for it?<br>
<br>
Passing a VRT_CTX to the VFP init function could help grab a req or bo<br>
and stash it in vfp_entry::priv1, but I don't see a way to do that<br>
today without cheating.<br>
<br>
*cough* THR_GetBusyobj() *cough*<br>
<br>
Cheers,<br>
Dridi<br>
</blockquote></div>