Did you understand the RMI thing instead? My wild guess is that you're running your program in a container of some sort (e.g. an application server), or using a framework like Spring that allows to publish services via RMI. Then you might not find any mention of RMI in PRISM's sources.
On Wed, Nov 26, 2014 at 9:16 AM, Mark Evenson evenson@panix.com wrote:
On 25 Nov 2014, at 23:41, Robert Goldman rpgoldman@sift.net wrote:
At the expense of following up on my own thread.....
I have Java code that is calling Lisp according to some of the examples I have read.
I make a single Interpreter object, then I look up a function as defined
in
ABCL.
I store these both on the java object that calls the ABCL function.
Then multiple times I call <function>.execute() and catch the result.
Could I inadvertently be creating a lot of LispThreads, causing my system to eventually slow down and lock up?
Every call to Function.execute() will run in the invoking thread, so unless the invoked call path explicitly spawns a new thread, there should only be as many threads present as you are invoking. LispThread is essentially a wrapper around a JVM thread that maintains a multi-threaded consistent view of the singleton Lisp environment as that JVM thread executes Lisp code.
As for “catch the result”: do you just mean act on the return value, or are you using a Java catch clause?
Any chance you can put the source up publicly for me to have a shot at running it?
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel