Responsiveness during longer computational processes

[StefanoLanzavecchia]

There's a fundamental difference.

If you define
[]NA 'I kernel32|SomeFunction& I'
and if you have

[0] foo x
...
[4] SomeFunction 20
if you call foo&1, the APL thread, which is executed inside the cooperative environment of the interpreter, at line 4 becomes an OS thread freeing the GUI thread and keeping your application responsive.

If, instead, you define
[]NA 'I kernel32|SomeFunction I'
and have a foo

[0] foo x
...
[4] SomeFunction&20
if you call foo from the GUI thread (thread 0 in most APL applications), when you spawn a new thead in line 4 the thread will block the whole interpreter because it's an APL thread executing an external function and the interpreter cannot switch APL thread while executing SomeFunction.

That's why I recommend the first usage pattern, if the way you designed your code permits you to run the whole "foo" in parallel, because that way when it gets to execute SomeFunction it won't block the entire interpreter.

[Budgie]

How would you do this for a .NET method?

[StefanoLanzavecchia]

I would ask John Daintree, I am afraid... As far as I can tell, there's no way right now. And I'd love to be proven wrong.

[PhilGray]

Stefano .. Perfect !
Problem solved ... perfect solution, much appreciated.

I think this should be included in the ⎕NA section of the manual, as it is IMO very important to know .
... I did read the manual BTW !
;-)

[JohnD|Dyalog]

How would you do this for a .NET method?

Dyalog always creates an OS (or .Net) thread for .Net functions on new APL threads. So, any .Net function executed from a new APL thread will allow other APL threads to run concurrently.