Like I've said before, I think name lookup can be a _lot_ faster with an
inline cache. Plus a lockfree hash table.
On Thu, 9 Jun 2022, Henry Rich wrote:
No, no - each task could have its own instance locale, which it passes
to all functions in the task, including its descendants.
The implementers can only do so much. Language design must help. For
example, if you had the idea to make local names in explicit definitions
somehow visible outside the definition, you would force the implementer
to lock those names each time they are used, a noticeable degradation.
Henry Rich
On 6/9/2022 11:53 AM, Elijah Stone wrote:
I maintain--masochistically, perhaps :)--that the correct approach to
language design is 'punish the implementors'.
The issue with putting some 'tls' locale in the search path is that it
is anti-modular. If everybody has to share that one locale for tls
data--somehow; coordinating that is probably also difficult, though I
am no locale expert and don't love the mechanism--then there is the
possibility of name collisions--exactly the problem that locales are
supposed to solve (and which my approach solves)!
On Thu, 9 Jun 2022, Henry Rich wrote:
'Annoying' doesn't begin to describe my reaction to adding another
layer to name lookup! :)
The task inherits the implied locale and thus the search path of the
originating task. You could run the task in an instance locale. If
you want to share names, you can run subtasks in their own instances,
using the search path to give access to all namespaces.
Henry Rich
On 6/9/2022 11:37 AM, Elijah Stone wrote:
If you use a numbered locale, you need to pass it around everywhere,
which is annoying. You can't put a reference to the locale in a
global variable, since that would defeat the purpose of being thread
local.
On Thu, 9 Jun 2022, Henry Rich wrote:
What need does this address? Can it be met by having a numbered
locale to hold the task variables? What happens when a task spawns
a task - you'd want to access them all, I assume?
Henry Rich
On 6/9/2022 9:20 AM, Elijah Stone wrote:
On Thu, 9 Jun 2022, Raul Miller wrote:
"task local storage" rather than "thread local storage"
Yes. That's what I meant, but I was not clear enough.
local variables accomplish something similar
Local variables are not meaningfully mutable. IOW they are not
really _state_.
how to clean this up
Task constructors and destructors might be a good idea, and do
have prior art.
how to debug issues related to it
What do you mean?
shorter duration
If I have my way, tasks and threads will be orthogonal. If a task
migrates from one thread to another--and the former dies--it
should maintain its local state.
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
