Vagrant Cascadian wrote:
> On 2024-04-16, Chris Lamb wrote:
>> However, I think this first iteration of --hard-timeout time has a few
>> things that would need ironing out first, and potentially make it not
>> worth implementing:
>>
>> (1) You suggest it should start again with "--max-container-depth 3",
>> but it would surely need some syntax (or another option?) to control
>> that "3" (but for the second time only).
>
> What about going the other direction ... starting with a very small
> value for max-container-depth, and incrementally increasing it,
> generating a report (or at least storing sufficient data to generate
> one) in between each increment, so you always get some information, but
> essentially incrementally increase the resolution?
>
> Or would that approach just be too inefficient?
This is probably a separate required best suited to another issue at
this point, but I do like the idea of being able to incrementally
increase the resolution over time. Depending on how it worked in
practice, there should not be significant overhead in managing this
if, say, the commands that could not be run "in time" would have token
placeholders internally that rendered to text in the output rather
than non-trivial/expensive binary diffs.
On the negative side though, I think this would still require a robust
way of killing long-running processes as outlined previously. But
moreover it would require a HUGE reworking of how diffoscope handles
containers and recurses into nested structures in its tree-like style.
Indeed, thinking about it, this change would pretty much be exactly
the same work needed to make diffoscope run in parallel (!) which
hopefully communicates both the scope of the changes that would be
needed to achieve this, and that making diffoscope run in parallel
also has other benefits. Anyway, mini brain dump over.
Regards,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org 💠
⬊ ⬋
o
