👋 I'm interested in pursuing https://github.com/pantsbuild/pants/issues/21626 to add a "minimum level of concurrency" to the process execution. The use case is to give a process a minimum level of resources, in our case, to provide stability for resource heavy integration tests. I have a very basic implementation working, so I've gotten surface level familiar with the relevant code in

<http://bounded.rs|bounded.rs>

and the process struct to pass through to python. I'm looking for some guidance on how to proceed with this and what you think the best path would be. The major questions I see are: - How should the api surface change on

Process

? Is this a new field?

concurrency_required

? - How should this interact with process presumption and

concurrency_available

? Are they mutually exclusive or can they both be specified? If you're curious, my very basic implementation just swaps the

self.sema.acquire()

for

self.sema.acquire_many(count)

(in addition to other argument plumbing) which allows the task to fully block until the desired concurrency is available

Hmmm, interesting question. Off the top of my head, I think this is orthogonal to

concurrency_available

?

concurrency_available

is a hint to the engine to say “this process could benefit from this much concurrency”, if available. Your

concurrency_required

would (in addition) set a minimum. But

concurrency_available

could still be used as a hint that going above the minimum would be beneficial.

To preserve compatibility on the python side we might want to preserve taking an int too. Making the type something like

int | Range(min: int | None, max: int | None) | Exclusive

I don't think the Range should require the max value, so inputs like

Range(min=2)

can set min requirement without requesting any additionally concurrency. Is

Exclusive

is just a shorthand type for Range(min=max slots)? Where the implementation would need to acquire all slots I don't know enough about the py/rust bindings to know if a type like that is easy to implement, or if going with the additional property would be significantly easier

Well, we’d need a new property anyway, because the name is no longer a fit… But the idea is that we could eventually deprecate the old property because the new one subsumes it.

Makes sense. Is there an example of a similar style enum type I can use as a reference?

Hmmm

Yeah and to do the binding between the two languages

I’ll take a look