integration with java's threading
evenson at panix.com
Mon Mar 13 07:18:25 UTC 2017
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
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
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.
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.
"A screaming comes across the sky. It has happened before, but there
is nothing to compare to it now."
More information about the armedbear-devel