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/ExecutorServi...
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/packag...
Happy threading, Mark