starseeker (Feb 07 2025 at 00:50): starseeker (Feb 07 2025 at 00:50):@Sean Am I correct that we (and users) should only ever use rt_uniresource for non-parallel scenarios? (i.e. ncpu = 1)? If so, should we be enforcing that in prep by validating that resource pointers aren't &rt_uniresource if ncpus > 1?
Sean (Feb 07 2025 at 01:05):I mean we could, but it's also possible to hang a parallel structure off the rt_uniresource, in which case you might just have rt_uni with ncpu>1
starseeker (Feb 07 2025 at 01:05):OK, so there is a way to do that legitimately? Fair enough.
Sean (Feb 07 2025 at 01:08):"Legitimate" is up for debate.
Sean (Feb 07 2025 at 01:08):We do say that the resources are supposed to be per thread of execution, so even if it's technically possible, that's not documented use.
Sean (Feb 07 2025 at 01:09):And definitely not kosher for passing rt_uniresource around to librt functions from different threads simultaneously.
starseeker (Feb 07 2025 at 01:09):What about doing the check by default and having some sort of #ifdef REALLY_WANT_PARALLEL_UNIRESOURCE guard to allow a code that's specifically trying something wonky to disable it?
Sean (Feb 07 2025 at 01:09):There are statistical aggregators in there that assue one per thread
Sean (Feb 07 2025 at 01:10):I wouldn't bother. If you want to add it, just update the doc for rt_uniresource to state the limitation/expectation.
Sean (Feb 07 2025 at 01:11):Maybe make sure it's consistent with the docs for struct resource, but that might be good already.
starseeker (Feb 07 2025 at 01:12):Gotcha. I'll look more closely tomorrow.
Last updated: Feb 12 2025 at 00:46 UTC