That's an excellent idea.
Henry Rich
On 4/29/2022 2:35 PM, 'robert therriault' via Beta wrote:
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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
