If you were looking at a group effort on creating the threading mechanism, could this be an area where the wiki could have a use that has not been exploited in the past? It allows for multiple contributions and revisions and discussion as well as tracking changes.
Cheers, bob > On Apr 29, 2022, at 10:35, Henry Rich <[email protected]> wrote: > > Thread creation needs to have arguments for expandability. What is now '' > may be who-knows-what in the future. > > Given that a primitive to allocate a single thread suffices, I see no reason > to support more complexity in the primitive. > > I like your start: why not build the needed verbs in J as a group effort here? > > Henry Rich > > On 4/29/2022 1:01 PM, Jan-Pieter Jacobs wrote: >> 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 > > > -- > This email has been checked for viruses by AVG. > https://www.avg.com > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
