Responsiveness during longer computational processes
Forum rules
This forum is for discussing APL-related issues. If you think that the subject is off-topic, then the Chat forum is probably a better place for your thoughts !
This forum is for discussing APL-related issues. If you think that the subject is off-topic, then the Chat forum is probably a better place for your thoughts !
15 posts
• Page 2 of 2 • 1, 2
Re: Responsiveness during longer computational processes
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.
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.
-
StefanoLanzavecchia - Posts: 109
- Joined: Fri Oct 03, 2008 9:37 am
Re: Responsiveness during longer computational processes
How would you do this for a .NET method?
Jane
-
Budgie - Posts: 36
- Joined: Thu Nov 26, 2009 9:22 am
- Location: Beckenham
Re: Responsiveness during longer computational processes
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.
-
StefanoLanzavecchia - Posts: 109
- Joined: Fri Oct 03, 2008 9:37 am
Re: Responsiveness during longer computational processes
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 !
;-)
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 !
;-)
- PhilGray
- Posts: 50
- Joined: Sat Mar 13, 2010 7:55 pm
Re: Responsiveness during longer computational processes
Budgie wrote: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.
-
JohnD|Dyalog - Posts: 74
- Joined: Wed Oct 01, 2008 9:35 am
15 posts
• Page 2 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 1 guest
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group