1

I am contemplating two different methods of introducing concurrency to a Ruby program. I am currently forking the process, and having the forks communicate via the database.

I have recently found out about Revactor, which handles concurrency via Fibers. I have used fibers in the past and I am quite certain they could not run in parallel, yet they claim that the library allows this.

A: Is Revactor truly concurrent?

B: If so, does anyone have any figures or opinions on the speed implications of switching to Revactor from a Process.fork approach?

providence
  • 29,135
  • 13
  • 46
  • 62
  • You're aware of which Ruby implementations do and don't allow multiple CPUs to be used at once, right? – Andrew Grimm Sep 20 '11 at 22:20
  • No, I thought Processes from `#fork` would be handled at OS level. Which implementations are these? I am currently on 1.9.2-p180. – providence Sep 20 '11 at 23:19
  • You may want to have a look at http://stackoverflow.com/questions/56087/does-ruby-have-real-multithreading – Andrew Grimm Sep 20 '11 at 23:21
  • That is a good resource, thanks for the link. However, I believe that is specific to threading, whereas I am looking at Process forking which (I believe) occurs at the OS level, as it is an alias for the Unix fork command. – providence Sep 20 '11 at 23:55
  • It was more to reply to "I am quite certain they could not run in parallel". – Andrew Grimm Sep 20 '11 at 23:58
  • Oh, right. In that case, I was certain because the lib uses Fibers as opposed to Threads. Can fibers be parallel-ized in, say, JRuby? – providence Sep 21 '11 at 00:05
  • I assumed so, but I don't have any factual basis to back that up. – Andrew Grimm Sep 21 '11 at 23:43

1 Answers1

0

Revactor is "single threaded with fibers" (so just one fiber at a time). This is theoretically better than "multi threaded" since it does provide concurrency but just requires one thread, so it can scale to lots of "threads" (fibers).

rogerdpack
  • 62,887
  • 36
  • 269
  • 388