polyphony 0.27 → 0.28

data/docs/technical-overview/exception-handling.md

@@ -1,6 +1,19 @@
+---
+layout: page
+title: Exception Handling
+nav_order: 4
+parent: Technical Overview
+permalink: /technical-overview/exception-handling/
+---
 # Exception Handling
 
-Ruby employs a pretty robust exception handling mechanism. An raised exception will bubble up the call stack until a suitable exception handler is found, based on the exception's class. In addition, the exception will include a stack trace showing the execution path from the exception's locus back to the program's entry point. Unfortunately, when exceptions are raised while switching between fibers, stack traces will only include partial information. Here's a simple demonstration:
+Ruby employs a pretty robust exception handling mechanism. An raised exception
+will bubble up the call stack until a suitable exception handler is found, based
+on the exception's class. In addition, the exception will include a stack trace
+showing the execution path from the exception's locus back to the program's
+entry point. Unfortunately, when exceptions are raised while switching between
+fibers, stack traces will only include partial information. Here's a simple
+demonstration:
 
 _fiber\_exception.rb_
 
@@ -28,7 +41,11 @@ Traceback (most recent call last):
 fiber_exception.rb:4:in `fail!': foobar (RuntimeError)
 ```
 
-So, the stack trace includes two frames: the exception's locus on line 4 and the call site at line 9. But we have no information on how we got to line 9. Let's imagine if we had more complete information about the sequence of execution. In fact, what is missing is information about how the different fibers were created. If we had that, our stack trace would have looked something like this:
+So, the stack trace includes two frames: the exception's locus on line 4 and the
+call site at line 9. But we have no information on how we got to line 9. Let's
+imagine if we had more complete information about the sequence of execution. In
+fact, what is missing is information about how the different fibers were
+created. If we had that, our stack trace would have looked something like this:
 
 ```text
 Traceback (most recent call last):
@@ -39,9 +56,19 @@ Traceback (most recent call last):
 fiber_exception.rb:4:in `fail!': foobar (RuntimeError)
 ```
 
-In order to achieve this, Polyphony patches `Fiber.new` to keep track of the call stack at the moment the fiber was created, as well as the fiber from which the call happened. In addition, Polyphony patches `Exception#backtrace` in order to synthesize a complete stack trace based on the call stack information stored for the current fiber. This is done recursively through the chain of fibers leading up to the current location. What we end up with is a record of the entire sequence of \(possibly intermittent\) execution leading up to the point where the exception was raised.
+In order to achieve this, Polyphony patches `Fiber.new` to keep track of the
+call stack at the moment the fiber was created, as well as the fiber from which
+the call happened. In addition, Polyphony patches `Exception#backtrace` in order
+to synthesize a complete stack trace based on the call stack information stored
+for the current fiber. This is done recursively through the chain of fibers
+leading up to the current location. What we end up with is a record of the
+entire sequence of \(possibly intermittent\) execution leading up to the point
+where the exception was raised.
 
-In addition, the backtrace is sanitized to remove stack frames originating from the Polyphony code itself, which hides away the Polyphony plumbing and lets developers concentrate on their own code. The sanitizing of exception backtraces can be disabled by setting the `Exception.__disable_sanitized_backtrace__` flag:
+In addition, the backtrace is sanitized to remove stack frames originating from
+the Polyphony code itself, which hides away the Polyphony plumbing and lets
+developers concentrate on their own code. The sanitizing of exception backtraces
+can be disabled by setting the `Exception.__disable_sanitized_backtrace__` flag:
 
 ```ruby
 Exception.__disable_sanitized_backtrace__ = true
@@ -50,7 +77,10 @@ Exception.__disable_sanitized_backtrace__ = true
 
 ## Cleaning up after exceptions
 
-A major issue when handling exceptions is cleaning up - freeing up resources that have been allocated, cancelling ongoing operations, etc. Polyphony allows using the normal `ensure` statement for cleaning up. Have a look at Polyphony's implementation of `Kernel#sleep`:
+A major issue when handling exceptions is cleaning up - freeing up resources
+that have been allocated, cancelling ongoing operations, etc. Polyphony allows
+using the normal `ensure` statement for cleaning up. Have a look at Polyphony's
+implementation of `Kernel#sleep`:
 
 ```ruby
 def sleep(duration)
@@ -61,13 +91,27 @@ ensure
 end
 ```
 
-This method creates a one-shot timer with the given duration and then suspends the current fiber, waiting for the timer to fire and then resume the fiber. While the awaiting fiber is suspended, other operations might be going on, which might interrupt the `sleep` operation by scheduling the awaiting fiber with an exception, for example a `MoveOn` or a `Cancel` exception. For this reason, we need to _ensure_ that the timer will be stopped, regardless of whether it has fired or not. We call `timer.stop` inside an ensure block, thus ensuring that the timer will have stopped once the awaiting fiber has resumed, even if it has not fired.
+This method creates a one-shot timer with the given duration and then suspends
+the current fiber, waiting for the timer to fire and then resume the fiber.
+While the awaiting fiber is suspended, other operations might be going on, which
+might interrupt the `sleep` operation by scheduling the awaiting fiber with an
+exception, for example a `MoveOn` or a `Cancel` exception. For this reason, we
+need to _ensure_ that the timer will be stopped, regardless of whether it has
+fired or not. We call `timer.stop` inside an ensure block, thus ensuring that
+the timer will have stopped once the awaiting fiber has resumed, even if it has
+not fired.
 
 ## Bubbling Up - A Robust Solution for Uncaught Exceptions
 
-One of the "annoying" things about exceptions is that for them to be useful, you have to intercept them \(using `rescue`\). If you forget to do that, you'll end up with uncaught exceptions that can wreak havoc. For example, by default a Ruby `Thread` in which an exception was raised without being caught, will simply terminate with the exception silently swallowed.
+One of the "annoying" things about exceptions is that for them to be useful, you
+have to intercept them \(using `rescue`\). If you forget to do that, you'll end
+up with uncaught exceptions that can wreak havoc. For example, by default a Ruby
+`Thread` in which an exception was raised without being caught, will simply
+terminate with the exception silently swallowed.
 
-To prevent the same from happening with fibers, Polyphony provides a mechanism that lets uncaught exceptions bubble up through the chain of calling fibers. Let's discuss the following example:
+To prevent the same from happening with fibers, Polyphony provides a mechanism
+that lets uncaught exceptions bubble up through the chain of calling fibers.
+Let's discuss the following example:
 
 ```ruby
 require 'polyphony'
@@ -83,5 +127,9 @@ spin do
 end.await
 ```
 
-In this example, there are four fibers, nested one within the other. An exception is raised in the inner most fiber, and having no exception handler, will bubble up through the different enclosing fibers, until reaching the top-most level, that of the root fiber, at which point the exception will cause the program to halt and print an error message.
+In this example, there are four fibers, nested one within the other. An
+exception is raised in the inner most fiber, and having no exception handler,
+will bubble up through the different enclosing fibers, until reaching the
+top-most level, that of the root fiber, at which point the exception will cause
+the program to halt and print an error message.
 

data/docs/technical-overview/extending.md

@@ -1,3 +1,10 @@
+---
+layout: page
+title: Extending Polyphony
+nav_order: 5
+parent: Technical Overview
+permalink: /technical-overview/extending/
+---
 # Extending Polyphony
 
 Polyphony was designed to ease the transition from blocking APIs and 

data/docs/technical-overview/fiber-scheduling.md

@@ -1,21 +1,108 @@
+---
+layout: page
+title: How Fibers are Scheduled
+nav_order: 3
+parent: Technical Overview
+permalink: /technical-overview/fiber-scheduling/
+---
 # How Fibers are Scheduled
 
-Ruby provides two mechanisms for transferring control between fibers: `Fiber#resume` / `Fiber.yield` and `Fiber#transfer`. The first is inherently asymmetric and is famously used for implementing generators and [resumable enumerators](https://blog.appsignal.com/2018/11/27/ruby-magic-fibers-and-enumerators-in-ruby.html). Another limiting factor of using resume / yield is that the root fiber can't yield away, limiting its usability as a resumable fiber.
+Ruby provides two mechanisms for transferring control between fibers:
+`Fiber#resume` /`Fiber.yield` and `Fiber#transfer`. The first is inherently
+asymmetric and is famously used for implementing generators and [resumable
+enumerators](https://blog.appsignal.com/2018/11/27/ruby-magic-fibers-and-enumerators-in-ruby.html).
+Another limiting factor of using resume / yield is that the main fiber can't
+yield away, limiting its usability as a resumable fiber.
 
-The second mechanism, using `Fiber#transfer`, is completely symmetric and allows use of the root fiber as a general purpose resumable execution context. Polyphony uses `Fiber#transfer` exclusively for scheduling fibers.
+The second mechanism, using `Fiber#transfer`, is completely symmetric and allows
+use of the main fiber as a general purpose resumable execution context.
+Polyphony uses `Fiber#transfer` exclusively for scheduling fibers.
 
 ## Scheduler-less scheduling
 
-Polyphony relies on [libev](http://software.schmorp.de/pkg/libev.html) for handling events such as I/O readiness, timers and signals. In most event reactor-based libraries and frameworks, such as `nio4r`, `EventMachine` or `node.js`, the reactor loop is run, and event callbacks are used to schedule user-supplied code *from inside the loop*. In Polyphony, however, we have chosen a programming model that does not use a loop to schedule fibers. In fact, in Polyphony there's no such thing as a reactor loop, and there's no *scheduler* running on a separate execution context.
-
-Instead, Polyphony maintains a list of scheduled fibers, fibers that will be resumed once the current fiber yields control, which will occur on every blocking operation. If no fibers are scheduled, the libev event reactor will be ran until one or more events have occurred. Events are handled by adding the corresponding fibers onto the *scheduled fibers* list. Finally, control is transferred to the first scheduled fiber, which will run until it blocks or terminates, at which point control is transferred to the next scheduled fiber.
+Polyphony relies on [libev](http://software.schmorp.de/pkg/libev.html) for
+handling events such as I/O readiness, timers and signals. In most event
+reactor-based libraries and frameworks, such as `nio4r`, `EventMachine` or
+`node.js`, the reactor loop is run, and event callbacks are used to schedule
+user-supplied code *from inside the loop*. In Polyphony, however, we have chosen
+a programming model that does not use a loop to schedule fibers. In fact, in
+Polyphony there's no such thing as a reactor loop, and there's no *scheduler*
+running on a separate execution context.
+
+Instead, Polyphony maintains for each thread a list of scheduled fibers, fibers
+that will be resumed once the current fiber yields control, which will occur on
+every blocking operation. If no fibers are scheduled, the libev event reactor
+will be ran until one or more events have occurred. Events are handled by adding
+the corresponding fibers onto the *scheduled fibers* list. Finally, control is
+transferred to the first scheduled fiber, which will run until it blocks or
+terminates, at which point control is transferred to the next scheduled fiber.
 
 This approach has numerous benefits:
 
-- No separate reactor fiber that needs to be resumed on each blocking operation, leading to less context switches, and less bookkeeping.
-- Clear separation between the reactor code (the `libev` code) and the fiber scheduling code.
-- Much less time is spent in reactor loop callbacks, letting the reactor loop run more efficiently.
-- Fibers are resumed outside of the event reactor code, making it easier to avoid race conditions and unexpected behaviours.
+- No separate reactor fiber that needs to be resumed on each blocking operation,
+  leading to less context switches, and less bookkeeping.
+- Clear separation between the reactor code (the `libev` code) and the fiber
+  scheduling code.
+- Much less time is spent in reactor loop callbacks, letting the reactor loop
+  run more efficiently.
+- Fibers are resumed outside of the event reactor code, making it easier to
+  avoid race conditions and unexpected behaviours.
+
+## A concrete example - fiber scheduling in an echo server
+
+Here's a barebones echo server written in Polyphony:
+
+```ruby
+require 'polyphony'
+
+server = TCPServer.open('127.0.0.1', 8081)
+while (client = server.accept)
+  spin do
+    while (data = client.gets)
+      client << ">>>you sent: #{data}"
+      break if data =~ /quit/i
+    end
+  end
+end
+```
+
+Let's examine the the flow of control in our echo server program:
+
+<p class="img-figure"><img src="../../assets/img/echo-fibers.svg"></p>
+
+> In the above figure, the fat blue dots represents moments at which fibers can
+> be switched. The light blue horizontal arrows represent switching from one
+> fiber to another. The blue vertical lines represent a train of execution on a
+> single fiber.
+
+- The main fiber (fiber 1) runs a loop waiting for incoming connections.
+- The call to `server.accept` blocks, and an I/O event watcher is set up. The
+  main fiber is suspended.
+- Since there's no other runnable fiber, the associated event loop is run.
+- An event is generated for the server's socket, and fiber 1 is added to the run
+  queue.
+- Fiber 1 is pulled from the run queue and resumed. The `server.accept` call
+  returns a new client socket (an instance of `TCPSocket`).
+- Fiber 1 continues by `spin`ning up a new fiber for handling the client. The
+  new fiber (fiber 2) is added to the run queue.
+- Fiber 1 goes back to waiting for an incoming connection by calling
+  `server.accept` again. The call blocks, the main fiber suspends, and switches
+  to the next fiber in the run queue, fiber 2.
+- Fiber 2 starts a loop and calls `client.gets`. The call blocks, an I/O event
+  watcher is set up, and the fiber suspends.
+- Since no other fiber is runnable, the event loop is run, waiting for at least
+  one event to fire.
+- An event fires for the acceptor socket, and fiber 1 is put on the run queue.
+- An event fires for the client socket, and fiber 2 is put on the run queue.
+- Fiber 1 is resumed and spins up a new client handling fiber (fiber 3), which
+  is put on the run queue.
+- Fiber 1 calls `server.accept` again, and suspends, switching to the next
+  runnable fiber, fiber 2.
+- Fiber 2 resumes and completes reading a line from the socket.
+- Fiber 2 calls `client.<<`, blocks, sets up an I/O watcher, and suspends,
+  switching to the next runnable fiber, fiber 3.
+- Fiber 3 resumes and calls `client.gets`. The call blocks, an I/O event watcher
+  is set up, and the fiber suspends.
 
 ## Fiber states
 
@@ -23,24 +110,45 @@ In Polyphony, each fiber has one of the following states at any given moment:
 
 - `:running`: this is the state of the currently running fiber.
 - `:dead`: the fiber has terminated.
-- `:paused`: the fiber is paused;
-- `:scheduled`: the fiber is scheduled to run soon.
+- `:waiting`: the fiber is suspended, waiting for something to wake it up.
+- `:runnable`: the fiber is on the run queue and will be run shortly.
 
 ## Fiber scheduling and fiber switching
 
-The Polyphony scheduling model makes a clear separation between the scheduling of fibers and the switching of fibers. The scheduling of fibers is the act of marking the fiber to be run at the earliest opportunity, but not immediately. The switching of fibers is the act of transferring control to another fiber, in this case the first fiber in the list of *currently* scheduled fibers.
+The Polyphony scheduling model makes a clear separation between the scheduling
+of fibers and the switching of fibers. The scheduling of fibers is the act of
+marking the fiber to be run at the earliest opportunity, but not immediately.
+The switching of fibers is the act of transferring control to another fiber, in
+this case the first fiber in the list of *currently* scheduled fibers.
 
-The scheduling of fibers can occur at any time, either as a result of an event occuring, an exception being raised, or using `Fiber#schedule`. The switching of fibers will occur only when a blocking operation is started, or upon calling `Fiber#suspend` or `Fiber#snooze`. In order to switch to a scheduled fiber, Polyphony uses `Fiber#transfer`.
+The scheduling of fibers can occur at any time, either as a result of an event
+occuring, an exception being raised, or using `Fiber#schedule`. The switching of
+fibers will occur only when a blocking operation is started, or upon calling
+`Fiber#suspend` or `Fiber#snooze`. In order to switch to a scheduled fiber,
+Polyphony uses `Fiber#transfer`.
 
-When a fiber terminates, any other scheduled fibers will be run. If no fibers are waiting and the main fiber is done running, the Ruby process will terminate.
+When a fiber terminates, any other scheduled fibers will be run. If no fibers
+are waiting and the main fiber is done running, the Ruby process will terminate.
 
 ## Interrupting blocking operations
 
-Sometimes it is desirable to be able to interrupt a blocking operation, such as waiting for a socket to be readable, or sleeping for an extended period of time. This is especially useful when higher-level constructs are needed for controlling multiple concurrent operations.
+Sometimes it is desirable to be able to interrupt a blocking operation, such as
+waiting for a socket to be readable, or sleeping for an extended period of time.
+This is especially useful when higher-level constructs are needed for
+controlling multiple concurrent operations.
 
-Polyphony provides the ability to interrupt a blocking operation by harnessing the ability to transfer values back and forth between fibers using `Fiber#transfer`. Whenever a waiting fiber yields control to the next scheduled fiber, the value received upon being resumed is checked. If the value is an exception, it will be raised in the context of the waiting fiber, effectively signalling that the blocking operation has been unsuccessful and allowing exception handling using the builtin mechanisms offered by Ruby, namely `rescue` and `ensure` (see also [exception handling](exception-handling.md)).
+Polyphony provides the ability to interrupt a blocking operation by harnessing
+the ability to transfer values back and forth between fibers using
+`Fiber#transfer`. Whenever a waiting fiber yields control to the next scheduled
+fiber, the value received upon being resumed is checked. If the value is an
+exception, it will be raised in the context of the waiting fiber, effectively
+signalling that the blocking operation has been unsuccessful and allowing
+exception handling using the builtin mechanisms offered by Ruby, namely `rescue`
+and `ensure` (see also [exception handling](exception-handling.md)).
 
-Here's a naive implementation of a yielding I/O read operation in Polyphony (the actual code for I/O reading in Polyphony is written in C and is a bit more involved):
+Here's a naive implementation of a yielding I/O read operation in Polyphony (the
+actual code for I/O reading in Polyphony is written in C and is a bit more
+involved):
 
 ```ruby
 def read_from(io)
@@ -70,7 +178,9 @@ ensure
 end
 ```
 
-In the above example, the `wait_readable` method will normally wait indefinitely until the IO object has become readable. But we could interrupt it at any time by scheduling the corresponding fiber with an exception:
+In the above example, the `wait_readable` method will normally wait indefinitely
+until the IO object has become readable. But we could interrupt it at any time
+by scheduling the corresponding fiber with an exception:
 
 ```ruby
 def timeout(duration)

data/docs/technical-overview.md

@@ -0,0 +1,10 @@
+---
+layout: page
+title: Technical Overview
+description: Lorem ipsum
+has_children: true
+section: true
+has_toc: false
+nav_order: 3
+section_link: /technical-overview/design-principles
+---

data/docs/user-guide/web-server.md

@@ -1,3 +1,10 @@
+---
+layout: page
+title: Web Server
+nav_order: 5
+parent: User Guide
+permalink: /user-guide/web-server/
+---
 # Web Server
 
 Polyphony's web server functionality offers a powerful and flexible way to

data/docs/user-guide.md

@@ -0,0 +1,10 @@
+---
+layout: page
+title: User Guide
+description: Lorem ipsum
+has_children: true
+section: true
+has_toc: false
+nav_order: 4
+section_link: /user-guide/web-server
+---

data/examples/core/xx-deadlock.rb

@@ -0,0 +1,8 @@
+# frozen_string_literal: true
+
+require 'bundler/setup'
+require 'polyphony'
+
+spin { sleep }
+
+sleep

data/examples/core/xx-state-machine.rb

@@ -0,0 +1,51 @@
+# frozen_string_literal: true
+
+# require 'bundler/setup'
+# require 'polyphony'
+
+require 'fiber'
+
+class StateMachine < ::Fiber
+  def initialize(state, rules)
+    @state = state
+    @rules = rules
+    super() { |input| state_loop(input) }
+  end
+
+  attr_reader :state
+  def state_loop(input)
+    loop do
+      @state = apply(input)
+      input = Fiber.yield(@state)
+    end
+  end
+
+  def apply(input)
+    f = @rules[@state][input]
+    return f.(@state) if f.is_a?(Proc)
+
+    raise 'Invalid input'
+  rescue => e
+    @state
+  end
+
+  def transition(input)
+    state = self.resume(input)
+    # state.is_a?(Exception) ? (raise state) : state
+  end
+end
+
+o = StateMachine.new(
+  :off,
+  {
+    off: { turnon: ->(s) { :on } },
+    on: { turnoff: ->(s) { :off } }
+  }
+)
+
+loop do
+  STDOUT << "#{o.state}: "
+  input = gets.strip.to_sym
+  # puts "  command: #{input.inspect}"
+  o.transition(input)
+end

data/examples/core/xx-trace.rb

@@ -0,0 +1,80 @@
+# frozen_string_literal: true
+
+require 'bundler/setup'
+require 'polyphony'
+
+Exception.__disable_sanitized_backtrace__ = true
+
+Gyro.trace(true)
+
+sleep 0
+$records = []
+
+trace = Polyphony::Trace.new { |r| $records << r }
+
+trace.enable
+
+f2 = spin(:f2) { 3.times { sleep 0.1 } }
+
+10.times {
+  spin { 3.times { sleep rand(0.05..0.15) } }
+}
+
+suspend
+trace.disable
+puts("record count: %d" % $records.size)
+
+analysis = Polyphony::Trace.analyze $records
+
+puts("fiber count: %d" % analysis[:by_fiber].size)
+puts
+
+worker_fibers = analysis[:by_fiber].keys - [Fiber.current]
+
+analysis[:by_fiber][f2].each { |r| 
+  case r[:event]
+  when /^fiber_/
+    STDOUT.orig_puts "#{r[:stamp]} #{r[:event]} (#{r[:value].inspect})"
+  else
+    STDOUT.orig_puts "#{r[:stamp]} #{r[:fiber]&.tag} #{r[:event]} (#{r[:value].inspect})"
+  end
+}
+
+state = 0
+run_wait_stamp = nil
+schedule_stamp = nil
+run_time = 0
+wait_time = 0
+schedule_count = 0
+schedule_acc = 0
+worker_fibers.each do |f|
+  analysis[:by_fiber][f].each { |r|
+    case r[:event]
+    when :fiber_create
+      state = 0
+      run_wait_stamp = r[:stamp]
+    when :fiber_schedule
+      schedule_count += 1
+      schedule_stamp = r[:stamp]
+    when :fiber_run
+      schedule_acc += r[:stamp] - schedule_stamp
+      wait_time += r[:stamp] - run_wait_stamp
+      state = 1
+      schedule_stamp = run_wait_stamp = r[:stamp]
+    when :fiber_switchpoint, :fiber_terminate
+      run_time += r[:stamp] - run_wait_stamp
+      state = 0
+      run_wait_stamp = r[:stamp]
+    end
+  }
+end
+
+puts(
+  format(
+    "f2 run: %f wait: %f schedule_count: %d avg schedule latency: %f",
+    run_time,
+    wait_time,
+    schedule_count,
+    schedule_acc / schedule_count
+  )
+)

data/examples/interfaces/pg_notify.rb

@@ -0,0 +1,35 @@
+# frozen_string_literal: true
+
+require 'bundler/setup'
+require 'polyphony/postgres'
+
+opts = {
+  host:     '/tmp',
+  user:     'reality',
+  password: nil,
+  dbname:   'reality',
+  sslmode:  'require'
+}
+
+db1 = PG.connect(opts)
+db2 = PG.connect(opts)
+
+spin_loop {
+  STDOUT << '.'
+  sleep 0.1
+}
+
+db1.query('listen foo')
+spin_loop {
+  db1.wait_for_notify(1) { |channel, _, msg| puts "\n#{msg}" }
+  STDOUT << '?'
+}
+
+spin_loop {
+  sql = format("notify foo, %s", db2.escape_literal(Time.now.to_s))
+  db2.query(sql)
+  STDOUT << '!'
+  sleep rand(1.5..3)
+}
+
+suspend

data/examples/io/xx-httparty.rb

@@ -3,11 +3,36 @@
 require 'bundler/setup'
 require 'polyphony'
 require 'httparty'
+require 'json'
 
-timer = spin { throttled_loop(100) { 
-  STDOUT << '.'
-} }
+def get_time(tzone)
+  res = HTTParty.get("http://worldtimeapi.org/api/timezone/#{tzone}")
+  return '- failed -' unless res.ok?
 
-res = HTTParty.get('http://worldtimeapi.org/api/timezone/Europe/Paris')
-puts res
-timer.stop
+  json = JSON.parse(res.body)
+  Time.parse(json['datetime'])
+end
+
+zones = %w{
+  Europe/London Europe/Paris Europe/Bucharest America/New_York Asia/Bangkok
+}
+# zones.each do |tzone|
+#   spin do
+#     time = get_time(tzone)
+#     puts "Time in #{tzone}: #{time}"
+#   end
+# end
+
+# suspend
+
+def get_times(zones)
+  Polyphony::Supervisor.new do |s|
+    zones.each do |tzone|
+      s.spin { [tzone, get_time(tzone)] }
+    end
+  end
+end
+
+get_times(zones).await.each do |tzone, time|
+  puts "Time in #{tzone}: #{time}"
+end

data/examples/io/xx-irb.rb

@@ -1,8 +1,8 @@
 # frozen_string_literal: true
 
 require 'bundler/setup'
-require 'polyphony'
 require 'irb'
+require 'polyphony/irb'
 
 $counter = 0
 timer = spin do
@@ -11,16 +11,6 @@ timer = spin do
   end
 end
 
-# readline blocks the current thread, so we offload it to the blocking-ops
-# thread pool. That way, the reactor loop can keep running while waiting for
-# readline to return
-module ::Readline
-  alias_method :orig_readline, :readline
-  def readline(*args)
-    Polyphony::ThreadPool.process { orig_readline(*args) }
-  end
-end
-
 at_exit { timer.stop }
 
 puts 'try typing $counter to see the counter incremented in the background'

data/examples/io/xx-switch.rb

@@ -0,0 +1,15 @@
+# frozen_string_literal: true
+
+require 'fiber'
+
+X = 10_000_000
+
+main = Fiber.current
+f = Fiber.new do
+  loop { main.transfer }
+end
+
+t0 = Time.now
+X.times { f.transfer }
+dt = Time.now - t0
+puts "#{X / dt.to_f}/s"