Indeed you're right that putting 0&T.@''^:] n at the top spins up extra threads if loaded multiple times.
Creating up to y threads is also easy, though a little longer (untested): ensureythreads=: 0&T.@''^:(] - 1&T.@'') However, I wonder, would it make sense for these mundane tasks that don't seem to need extra arguments (or at least most of the time) to change the allocation of monad-dyad for T.? Then setting the debug thread (which looks to me like a less common task for a user) would become dyadic (e.g. 8 T. n), while T. 0 to T. 3 could mean, where needed as a synonym, the same as 0 T. '' to 3 T. ''. In addition, as boxes are not numbers, T. on boxes/pyxes could do what 4 T. list_of_boxes does now. That would leave only the (to my feeling) less common 5,6,7 (and the proposed 8) T. as necessarily dyadic. With this, ensureythreads above could be written less noisily as: T.@0^:(] - T.@1) I agree that creating a nice interface would not be a bad thing, and now is the moment to do so, I think. I also like the format of boxed arguments to create n threads with options. Although spinning up the threads is likely only going to show up once in a program, the other variants of T. will likely show up more often, so could benefit from a good interface. Anyway, just my thoughts, and in no way I pretend they are good ideas... just sharing. Jan-Pieter Op vr 29 apr. 2022 om 17:44 schreef Raul Miller <[email protected]>: > On Fri, Apr 29, 2022 at 11:31 AM Henry Rich <[email protected]> wrote: > > The issues you mention of how many threads to use and how to use them > > efficiently when there are many tasks have generated considerable debate > > among the implementers. > > Unless the consequent reasoning is explained, clearly and simply > (like: in the wiki), we're going to be motivated to reinvent it when > we run into its issues. > > (Even with clear coverage, we're still going to be touching on the issues > occasionally, as we bring new people on board, or possibly when we are > focusing on other issues and are distracted over here.) > > Maybe this will motivate library implementation. Maybe this will > motivate FAQ writing. Maybe this will motivate something else. > > ... > > Thanks, > > > -- > Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
