QuadDMX

[paulmansour]

I'm investigating ⎕DMX. I thought using it to replace the old family of non-thread safe ⎕DM, etc functions would be trivial, provided all the code was running in the same thread. But it appears the localization concept of ⎕DMX means that upgrading to ⎕DMX is not as simple as replacing ⎕DM with ⎕DMX.DM, etc. Even though all signalling and trapping and referencing code is running in the same thread, I may need to re-architect things. Is that a true statement?

[Morten|Dyalog]

Hi Paul... Oh why can't people start using new features right after we design them, while we can still clearly remember the rationale ? :-)

I believe that you should only need to "re-architect" if:

1) You are using more than one thread and expecting to be able to inspect errors occuring in one thread from another (be quick, before something else gets trapped!).

2) You need to refer to the details of an "old"error at some other time than during the first trap statement which is reacting to it. With ⎕DMX.DM you can't do this, with ⎕DM you might sometimes be able to get away with it.

In both cases, it would seem to me that, unless you are able to selectively write crashing and non-crashing code with 100% predicatability, your code probably didn't always work as expected already.

Of course, we may have missed something in the design - can you give an example of a scenario that you think you might need to re-architect?

[paulmansour]

Morten,

Thanks. On further review, it looks my particular case did indeed involve 2 threads...

Paul

[paulmansour]

So, I made a typo, adding an extra quad, and did this:

      ⎕DMX.⎕DM

and I did not get an error. Interesting. There is also a ⎕IO in there. And you can assign it. Even more interesting.

Then I did:

      ⎕DMX.MyVar←⍳10

and then

      ⎕DMX.MyVar
0 1 2 3 4 5 6 7 8 9

Lo and behold, thread local storage! At least until the next error, which seems to create a new instance.

I guess the question is, why not have ⎕TSTORE or some such?