Re: [PATCH datacenter-manager 11/20] parallel fetcher: pass arguments to closure in a single type

[Robert Obkircher <r.obkircher@proxmox.com>]

On 24.08.26 15:13, Lukas Wagner wrote:
> On Fri Aug 21, 2026 at 4:00 PM CEST, Robert Obkircher wrote:
>>> +
>>> +extern "C" fn cleanup() {
>>> +    if let Some(dir) = STATIC_TEMP_DIR.get() {
>>> +        let _ = std::fs::remove_dir_all(dir);
>>> +    }
>>> +}
>>> +
>>> +pub fn test_setup() {
>>> +    static INIT: Once = Once::new();
>>> +
>>> +    INIT.call_once(|| {
>>> +        let file_opts = CreateOptions::new();
>>> +
>>> +        let dir = proxmox_sys::fs::make_tmp_dir("/tmp", None).unwrap();
>> A while ago I had a brief discussion with Fabian about how file I/O
>> should be tested. He argued that tests should not make any assumptions
>> about the file system outside of CARGO_TARGET_TMPDIR, not even about
>> /tmp.
>>
>> But that is only available for real integration tests, not for
>> unittests.
> Yeah, might make it sense to use it for the tests here, I guess.
>
> Right now, we have quite a few unit tests in PDM which use /tmp anyways,
> for exactly the reason you mentioned. Wondering if there is any sensible
> approach for these.
>
>>> +        STATIC_TEMP_DIR.set(dir.clone()).unwrap();
>>> +
>>> +        proxmox_rest_server::init_worker_tasks(dir.clone(), file_opts).unwrap();
>>> +        proxmox_access_control::init::init(&pdm_api_types::AccessControlConfig, dir)
>>> +            .expect("failed to setup access control config");
>>> +
>>> +        unsafe {
>>> +            libc::atexit(cleanup);
>> Doesn't this potentially delete files while other threads are stil
>> accessing them?
> Its a bit of a crutch admittedly, but I think in the context of integration tests
> this should not be a huge issue? If exit() is called, any remaining
> thread is stopped anyway; it should not be a big deal if any file IO in
> the temporary directory fails then?
>
> Admittedly, I haven't examined the exact behavior of rust's test runner,
> so maybe I'm missing something here.
I was worried that a panic in one test could trigger confusing false
positives in others, because threads are stopped after the exit
handler runs.

But now that I think about it, cargo test --fail-fast probably catches
the panic and waits for running tests before exiting, so this
shouldn't be an issue.
>