On Fri, Apr 29, 2022 at 6:16 PM Henry Rich <[email protected]> wrote: > Yes: we would want a language of machine requirements. The code to > allocate threads would compare what is already allocated with what has > been requested and make the right decision. This makes it plain, does > it not, that this work should be outside JE, in the user's hands.
Sure, just be careful about what you identify as "this". That said, "what is already allocated" should only be significant in the sense of figuring out how many more threads are needed (because we do not track why the threads were allocated). So that should not be relevant to the user in this context. (How many threads are currently running is useful in a debugging sense -- it's useful to help the user understand how the machine works. But it should never be thought of as relevant for the purpose of figuring out how many threads are currently needed. That problem should be tackled at, at least, one level of abstraction higher.) And... that said, if it does turn out that in some obscure circumstance we want to dynamically allocate more threads based how many are currently running, a language primitive which gives us an implementation of "run Y threads" could still be used for that purpose. The only downside I am seeing here is that this mechanism would need to assert a lock, to lock out other instances of itself while it checks the current number of running theads, and while it is incrementing towards the needed number of threads. But that is work that will have to be done every time this mechanism is used, if programmers are going to use this mechanism at all. So I am having trouble seeing this as a downside. Do you anticipate any other sorts of problems with a "make sure Y threads are running" primitive? Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
