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