Warning about loading tilt/haml in a non thread-safe way
See original GitHub issueI’m seeing this warning in my Gradle-based project:
WARN: tilt autoloading 'tilt/haml' in a non thread-safe way; explicit require 'tilt/haml' suggested.
The same warning also shows up in this sample project: https://github.com/JGrenier/asciidoclet-sample
I’m using Gradle 2.6.
Issue Analytics
- State:
- Created 8 years ago
- Comments:93 (70 by maintainers)
Top Results From Across the Web
'sass' in a non thread-safe way - ruby on rails - Stack Overflow
I'm getting these warnings when trying to use sass in Rails 3.1 rc1. WARN: tilt autoloading 'sass' in a non thread-safe way; explicit ......
Read more >Writing reentrant and threadsafe code - IBM
In single-threaded processes, only one flow of control exists. The code executed by these processes thus need not be reentrant or threadsafe.
Read more >Thread Safety in Java | DigitalOcean
Thread safety in java is the process to make our program safe to use in multithreaded environment, there are different ways through which...
Read more >What is thread safe or non-thread safe in PHP - GeeksforGeeks
Thread-safe : It is used to ensure that when the shared data structure which is manipulated by different threads are prevented from entering ......
Read more >C/C++ Thread Safety Analysis - Google Research
on loads or stores to variables. It checks that the appropriate capability is in the current set, and issues a warning if it...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

… perhaps we should upgrade asciidoclet to the latest asciidoctorj as well then.
@johncarl81 for some reason your exec:java is not working for me but if I generate with package in your last changes to pom.xml the shaded jar it generates will run. So both my instincts seem to be right:
I get 50 iterations consistently so what we generate when switching to full build is broken. Also if set threshold to -1 then no full build is performed and all is working:
So at this point we know we have a bug in full build (which would also occur in JIT itself if it was enabled) and we know what code is doing it. My cursory examination of code in question in its internal representation actually looks ok so next steps is to see how different it looks for real. Perhaps extracting that snippet by itself was inadequate.