Responsiveness during longer computational processes

[PhilGray]

During a longer process ( such as copying many files using any APL routine ), the User's APL-window remains effectively ( for all intents and purposes ) frozen.

e.g. Whilst APL is processing, the Window cannot even be "moved" using the mouse.
i.e. it may react to the "move" say 5 seconds later.

I've tried a few experiments using the "Yield" property , but the result is not really what I was hoping for.

Does anyone have any suggestions ?
TIA

[paulmansour]

Multithreading with spawn: &

I can probably dig up some actual examples if needed.

[PhilGray]

Paul, I've already tried that ( spawn ) and the result was not much different.
Thx all the same.

I also rewrite the Caption of a GUI-label during each step of the process. Doesn't help much though.

[paulmansour]

This is one of the things that & is expressly for I think. You must be doing something wrong, or the particular long running process must not allow the interpreter to thread-switch, or I don't really know what you want to do. Probably the latter.

Perhaps your ampersand is not placed at the proper level in your code?

[PhilGray]

It was a simple Niladic function that contains a loop around a "CopyDir" function amongst other things ( a few []NA functions for creating/deleting directories etc).

e.g. {RUNBACKUP}& 0

I have used threads extensively before, for other purposes. But in this case , I am just executing a simple repetitive loop ( file copying ) until finished.

Perhaps your ampersand is not placed at the proper level in your code?

This is of course the next option, to multithread deeper in the code .. preferred of course to avoid if possible. I will try it and come back.

OK.. back again : No difference at all.

The "response" problem has more to do with the time-window APL gives-up to Windows I presume, which is why I thought that using the Root property ('.'⎕WG 'Yield' ) would help, I went as low as "20" without any noticeable change in the responsiveness.

I guess there's no perfect solution, other than maybe calling "Sleep" at the OS level !
;-)

[paulmansour]

Sounds like you know what your doing, and it should work. According to the manual, thread switching can occur during []NA, so I don't see why the GUI is not immediately responsive. I don't think moving the & down will help, but moving it up might. If the function is a callback you can thread it at the topmost level directly:

Button.onSelect←'LongRunningFoo&'

Maybe that will help.

[PhilGray]

you can thread it at the topmost level directly

Thanks, & yes, that is actually the first thing I did !

[PhilGray]

Paul, maybe the Dyalog guys might have an idea , as this "effect" is not unknown as far as I know.
I had always presumed he "Yield" property might alleviate the problem somewhat.
.. obviously doesn't seem to be the case ( I haven't tried "Yield 1" yet of course ).

By default, Dyalog APL/W yields control to Windows approximately every 1/5th of a second. This is implemented by checking the time at the beginning of each line of executable APL code and yielding if 1/5th of a second or more has elapsed since the last yield. This mechanism also allows APL to detect user interrupts (which are simply Windows messages) during the execution of code.
..
..
The value of Yield is an integer expressed in 1/1000's of a second. Its default value is 200. Yield defines the period of time allowed to elapse between the execution of successive lines of APL code before APL yields to Windows by requesting a message from the Windows queue. If Yield is set to zero APL does not explicitly yield.

I just tried setting the Yield to 1, with slightly better results.
As I said, it's not really critical , just would have been nicer "Not" to have a frozen window for ca. 10 seconds.
Thanks for your time - appreciated.

[StefanoLanzavecchia]

How about putting the "&" inside the definition of []NA, especially if it's a file copy operation? That should definitely untie the GUI thread...

[PhilGray]

Stefano, rather than putting it "inside the definition", I placed it during the "Call" which I think makes more sense. However, the result was slightly better, but the Window movement was still rather "lumpy".
Not to worry , I can live with this unless the guys at Dyalog suggest a better solution.