safety and reusability of clojure.lang.RT, Compiler and co. in multi-classloader environment

[Georgi Danov]

Hi,
 I am integrating clojure into java micro container. It has hierarchical classloaders and can restart modules on the fly. It's almost REPL for Java :).

 I have clojure running inside it, but even after reading some of the RT and Compiler classes source code I don't understand well enough how much state is accumulated where (theadLocals, static class fields/Vars, classloader, so on). Given that I don't want to have each module run different clojure version, I would prefer to have the basic things loaded once and shared.

 I am also not sure what is shareable — I see the RT class has some static init functionality that appears to be safe for sharing the same clojure.jar classloader with all modules, but can't be sure.
 
 Would be glad if there is article I have missed that outlines this.

Thanks,
Georgi

[Stephen Gilardi]

I haven’t seen discussion of isolating some of the RT data structures while sharing others and the executable parts.

In case you haven’t seen these, here are some references about isolated Clojure runtimes that may be helpful:

https://github.com/boot-clj/boot and its “pods” facility: https://github.com/boot-clj/boot/tree/master/boot/pod which uses https://github.com/projectodd/shimdandy .

More on pods: https://github.com/boot-clj/boot/wiki/Pods

A presentation about boot (including pods): https://www.youtube.com/watch?v=TcnzB2tB-8Q .

—Steve

https://github.com/projectodd/shimdandy

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gary Trakhman]

Here is another interesting read about how they solved it in immutant: http://immutant.org/news/2012/05/18/runtime-isolation/

[Toby Crawley]

Note that that post is out of date - the runtime isolation pieces of
Immutant 1.x have been extracted into
https://github.com/projectodd/shimdandy (which Stephen mentioned).
Note that with shimdandy, shims *can't* share Clojure classes - each
shim will have its own copy. This is required if you want them to be
isolated from each other, or you want them to have different effective
classpaths. If you do give shimdandy a try, let me know if you have
any problems/questions.

- Toby

[Georgi Danov]

Thanks, that's exactly what was needed.

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/zl2cmsjs8Do/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Georgi Danov]

Toby, you might want to add one more thread leak — clojure.core.async.impl.timers/timeout-daemon, even though this is not official core lib

[Toby Crawley]

Thanks, I've updated the README with more notes about threads in
general, and core.async specifically.

- Toby

[Georgi Danov]

Just for the record, there is one more relevant thread
https://groups.google.com/d/topic/clojure/0AgUIiY8BQ8/discussion