Comments (14)
Our gem does not require any external dependency and every component is available in a full standard Ruby 1.9 implementation, so it should already run.
Do you the chance to try concurrent-ruby out on RubyMotion?
from concurrent-ruby.
@elcuervo I apologize, but my knowledge of RubyMotion is minimal. Are you asking if this gem will work with RubyMotion, or are you suggesting extending the gem with RubyMotion-specific optimizations?
This gem is 100% pure Ruby and should run under any compliant interpreter.
We have started to implement conditional JRuby-specific optimizations and are experimenting with CRuby/MRI-specific extensions as well. The idea is that the gem automatically detects which platform it is installed on and will include the relevant optimizations. If there is a way to implement similar optimizations on RubyMotion we'd be happy to explore that approach. So long as we provide a consistent API and behavior across all platforms we're happy to optimize when possible.
from concurrent-ruby.
Well, my knowladge is minimal as well. Here's the deal: I'm the author of airplay and I'm considering switching to concurrent-ruby
. I need more control on the things I'm doing right now, and I really love zero-dependency.
Some people are asking me to port the gem to be RubyMotion compatible and since I'll have to do that maybe it will make sense to work in a implementation for concurrent-ruby since I saw the jruby/rbx flags in the code.
I'm basically asking if I add a RubyMotion wrapper for the calls you'd be open to merge it. The idea is to use the GCD to handle thread dispatching.
from concurrent-ruby.
A new executor using GCD would make a lot of sense, and maybe some other primitives could directly use GCD such as queues and barriers. It would be really interesting to benchmark Ruby's primitives against GCD and Java.
from concurrent-ruby.
@elcuervo We'll happily support additional platform-specific optimizations.
Our rule is to have a pure-Ruby implementation of every class/module/abstraction in the gem but support platform-optimized implementations where able (we'll be adding CRuby extensions soon). So long as the GCD versions support the same API and exhibit the same behavior as the pure Ruby versions, we'd be happy to include it.
from concurrent-ruby.
Awesome. I'll start working on that and keep you in the loop. ❤️
from concurrent-ruby.
An issue right now that I see is that you're using require
in each file, which isn't supported in RubyMotion (since runtime require
isn't available). If you were to switch to something like motion-require and change all requires to require_relative
it might work, but likely have issues there as well. RubyMotion is mostly Ruby-compliant but not fully due to its compiled nature and having to abide by Apple's rules.
from concurrent-ruby.
For RubyMotion can you not just monkey patch require
to be motion_require
?
from concurrent-ruby.
Good question, I should try it. It would be awesome to have this gem available in RubyMotion.
from concurrent-ruby.
I recently purchased RubyMotion after seeing @lrz speak at Steel City Ruby. I haven't had a chance to work with it yet, but I do hope to make this gem compatible.
@jamonholmgren Any help you can provide would be greatly appreciated.
from concurrent-ruby.
@jdantonio I'd be happy to help. Right now a bit buried with client work but eventually I'll give it a go.
from concurrent-ruby.
@jamonholmgren Great. Thank you!
from concurrent-ruby.
I've played with this some. Since most of the classes are POROs, this is certainly possible to port at least some of this to RubyMotion. Monkeypatching require
to be a no-op does work (just tested it).
I think it might cause disruption in your code base beyond what you'd likely want to allow. For example, your Rakefile and Gemfile would both need to be split into two: one for RM and one for Ruby. C extensions won't be possible (I'm not sure yet how much of your code base relies on them). Specs will need to be somewhat rewritten. And I'm not sure what else yet.
It might be best to create a new RubyMotion-specific gem and copy over relevant code. Some of the classes could probably benefit from the use of GCD (Grand Central Dispatch) rather than using threads.
It's also possible that we could create a subfolder that holds the RubyMotion-specific code and refers back to the lib
folder for shared code.
Either way, it'll be a lot of work. Unless there's a lot of demand for it I'd recommend tabling the discussion for now. Much as I'd like to see this lib in RM, it's probably not worth doing quite yet.
from concurrent-ruby.
@jamonholmgren Thank you very much for taking the time to look into this. None of the C or Java code in the gem is necessary--everything is written in pure Ruby and native code optimizations are only triggered on supporting platforms. In theory we could follow that same pattern for RubyMotion, but so far there isn't any demand. Your recommendation to not pursue this right now seems like the wise approach.
from concurrent-ruby.
Related Issues (20)
- why use wait_for_termination method will stuck the code HOT 2
- DaemonThreadFactory creating new Java thread factory each time it creates a new thread HOT 8
- `Concurrent::Promises::Future#value!` can return `nil` even when promise is not resolved yet HOT 6
- Version 1.2.2 crashes with Segmentation fault HOT 3
- Fiber.new causes SEGV when using Ruby 3.3.0 on Rails 7.1.2 in M1 Mac Docker environment HOT 5
- Segfault in lock_local_var.rb on aarch64 HOT 3
- [REDIRECT] Segfault on Ruby 3.3.0 on linux-aarch64? See https://bugs.ruby-lang.org/issues/20085
- Add new CI job with RUBY_MN_THREADS=1 HOT 4
- Add API to prestart threads in threadpools HOT 4
- Don't know how to build task 'parallel_spec' HOT 2
- Segmentation fault related to concurrent-ruby HOT 4
- Segmentation fault with Ruby 3.3.0 running with Docker HOT 1
- Add keyword arguments to async HOT 1
- ThreadPoolExecutor#shutdown? inconsistency in JRuby and C Ruby HOT 4
- test failure due to "uninitialized constant Concurrent::CAtomicReference" HOT 7
- CAtomicFixnum should probably be a private constant HOT 1
- support re-raising exceptions when shutting down a timertask HOT 4
- v1.2.0 release notes do not mention that RubyThreadLocalVar class was removed HOT 8
- NameError: uninitialized constant Concurrent::RubyThreadLocalVar HOT 1
- The Concurrent::Map default_proc is passed a Concurrent::Hash instead of the Concurrent::Map HOT 8
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.
from concurrent-ruby.