headius / jo Goto Github PK
View Code? Open in Web Editor NEWImplementation of key Go (lang) features for (J)Ruby
License: MIT License
jo's People
Contributors
Stargazers
Watchers
jo's Issues
Comparing to other project
Wanted to say thanks for this project. I liked the concept of goroutines and wondered how it is possible on the JVM and Jruby.
Just wondering how your project compares to this gist.
https://gist.github.com/michaelfairley/4140714
Doesn't work in 1.7.4 in 1.9 or 2.0 mode
When I try the simple example on the main page I get:
Java::JavaUtilConcurrent::RejectedExecutionException: Task java.util.concurrent.FutureTask@55c5a59a rejected from java.util.concurrent.ThreadPoolExecutor@5768f863[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
from java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
from java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
from java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
from java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:132)
from com.headius.jo.JoLibrary$JoMethods.jo(JoLibrary.java:123)
from com.headius.jo.JoLibrary$JoMethods$INVOKER$s$0$0$jo.call(JoLibrary$JoMethods$INVOKER$s$0$0$jo.gen)
from org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:316)
from org.jruby.runtime.callsite.CachingCallSite.callBlock(CachingCallSite.java:145)
from org.jruby.runtime.callsite.CachingCallSite.callIter(CachingCallSite.java:154)
from org.jruby.ast.FCallNoArgBlockNode.interpret(FCallNoArgBlockNode.java:32)
from org.jruby.ast.NewlineNode.interpret(NewlineNode.java:105)
from org.jruby.ast.RootNode.interpret(RootNode.java:129)
from org.jruby.evaluator.ASTInterpreter.INTERPRET_EVAL(ASTInterpreter.java:95)
from org.jruby.evaluator.ASTInterpreter.evalWithBinding(ASTInterpreter.java:184)
from org.jruby.RubyKernel.evalCommon(RubyKernel.java:1130)
from org.jruby.RubyKernel.eval19(RubyKernel.java:1093)
... 118 levels...
from org.jruby.ast.BlockNode.interpret(BlockNode.java:71)
from org.jruby.evaluator.ASTInterpreter.INTERPRET_METHOD(ASTInterpreter.java:74)
from org.jruby.internal.runtime.methods.InterpretedMethod.call(InterpretedMethod.java:182)
from org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:186)
from org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:326)
from org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:170)
Can the busy wait be avoided?
If you comment out the producers from the select example the consumer uses 100% CPU since it's doing busy waiting. The loop in select does poll on the queues and then calls Thread.yield, which will let other threads run, but not in any way parks the thread until there are messages available.
Can this be avoided somehow? Ideally select should work like select in Go, or at least like IO.select.
The difference between Jo's select and Go's select is that in Go the goroutines will only wake up when there's a message available on any of the channels, and they will not occupy a thread while doing it. In Jo the thread doing the select will poll until there is a message available, using CPU and causing context switches.
The difference between Jo's select and IO.select is that using the latter will park the thread until there is data available in the socket buffer, the thread will not wake up and check if there is data available, so a process with only one thread that calls IO.select will not consume any CPU. In contrast to select on channels in Go, IO.select still blocks a thread, but that's not a problem if you don't run thousands of them.
In Go, goroutines are a language feature, but Clojure implements goroutines in core.async on the JVM, so it is possible. However, Clojure does it with macros, hiding the inversion of control that needs to happen, kind of how EM::Synchrony hides the callback spaghetti of EventMachine by using fibers.
One of the selling features of goroutines is that you can run hundreds of thousands of them without using up much memory. This is not possible with Jo the way it's currently implemented.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.