integration with java's threading

[Mark Evenson]

On 3/7/17 16:25, Devon Miller wrote:
> I saw that Bordeaux threads uses a very thin layer of java threads in their
> abcl implementation file.
> 
> I wanted to use some libraries from java that use threading fairly heavily
> (web apis) and was wondering if there had been good testing with exchanging
> data from the lisp layer to the java layer when threading is heavily used
> in the java layer. For example, passing xml and json s-expr into java for
> processing and sending out through a multi-threaded environment i.e. akka
> actors.

I have used Java threading heavily in production instances of ABCL
without encountering any problems.  As you have noticed by browsing
BORDEAUX-THREADS, there really isn't much Lisp-side code to the JVM
threads used by ABCL, so there isn't much to go wrong.

As for abstractions in handling threading, Lisp-based multi-threaded
servers like HUNCHENTOOT work well so if your application message
patterns follows the HTTP synchronous request/response pattern, it
should be easily to stretch existing code in that direction without
having to worry about signalling semantics.

If you need more complicated multi-thread communication mechanism,
LPARALLEL seems to provide a fine "bounded thread pool on queues"
mechanism that I have used to great success for long lived batch
processes whose lifetime is much greater than a typical HTTP
request/response sequence.

And if you really want to just do the threading in pure "Java the
Language", using the abstractions in
[java.util.concurrent][executor-service] with Lisp-side lambdas closed
over the data for a given worker will allow you to create almost any
multi-threaded service that I can imagine.

[executor-service]:
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html

In general, I find it much easier to reason about lexical variables in
multiple threads so I would avoid special variables until you develop
and can self- articulate an understanding of the ABCL/JVM memory model.

The only other gotcha in thread contention for memory might be in
reading/writing 64-bit JVM primitive values.  This might have "gone
away" in the 64bit JVMs that are prevalent today, as I haven't tested
this for a while.  If you run into problems, I would use the
[java-atomic][] JVM library to guard such access.

[java-atomic]:
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/package-summary.html

Happy threading,
Mark

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."