Google Drive
Gist
Clipboard
COSCUP2021 en COSCUP2021 RubyConf Taiwan 2021 TR214 - Ruby Conf請從這裡開始
Please feel free to help translate this document.
RubyDNS is a DNS client and server library for Ruby.EventMachine is a library for implementing scalable non-blocking programs for Ruby.Celluloid is a framework for Ruby actor-based concurrency which includes support for non-blocking I/O.
Celluloid::DNS was a fork of RubyDNS implemented on top of Celluloid.The Ruby fiber scheduler interface is specified in this document.
The CRuby implementation of the interface is in scheduler.c. The public interface (for use in C extensions, etc) is given in scheduler.h.
These are some other implementations (other than Async) of the fiber scheduler interface:
Socketry is an organisation for Async and related event-driven concurrency libraries for Ruby.
Async is a composable asynchronous I/O framework for Ruby. There are currently two branches: stable-v1 (for Ruby 2.x+) and main (for Ruby 3.x+). Currently, Async 2.0 (main) is not released yet due to CRuby bugs, but will be released at the latest by the end of the year with Ruby 3.1.0, and hopefully sooner with the release of Ruby 3.0.3.
#!/usr/bin/ruby
# gem install async
require 'async'
# Generate 10 random numbers between 0...10:
numbers = 10.times.map{rand(10)}
Async do
# For each number...
numbers.each do |number|
Async do |task|
# Sleep for that number:
task.sleep(number)
# Then print it out:
puts number
end
end
end
Event is a low level event readiness selector.
As discussed, there are 4 implementations:
If you would like to read more about io_uring, Linux Weekly News has a good overview.
#!/usr/bin/env ruby
require 'event'
require 'fiber'
# A pipe for communication:
input, output = IO.pipe
# An event readiness selector:
selector = Event::Selector.new(Fiber.current)
puts selector.class # implementation
# A fiber which will wait for the pipe to have data and print it out:
reader = Fiber.new do
selector.io_wait(Fiber.current, input, Event::READABLE)
puts input.read
input.close
end
# A fiber which will wait for the pipe to be writable and send a message:
writer = Fiber.new do
selector.io_wait(Fiber.current, output, Event::WRITABLE)
output.write "Hello World!"
output.close
end
# It will try to read but it's not ready:
reader.transfer
# It's ready to execute on the next event loop iteration:
selector.push(writer)
# Loop until the input is closed - i.e. we are finished:
until input.closed?
selector.select(1)
end
Falcon is an event-driven web server built on top of Async.
This example shows live streaming through a Rack application running on Falcon. It uses a special Async::HTTP::Body::Writable which can be used to send chunks of data from one task to the HTTP response.
Source code: https://github.com/socketry/utopia-falcon-heroku/blob/master/pages/beer/controller.rb
This example shows live client-server interaction with a application running in real time. The server state is synchronised to the client using a WebSocket.
This is the first time I tried to deploy such an application to Heroku, and I found some problems:
In any case, it's an interesting demo, showing the possibilies of event-driven concurrency in a web application.
You can make glider like this:
Then press "Start" button.
Feel free to add other fun shapes you find.
Source code: https://github.com/socketry/lively-falcon - you can run it locally too.
Async::Debug. It's a live debugger and can be used in any async program. It is currently quite simple, but I have some ideas to make it more useful for debugging live systems. Concurrency can be quite tricky, and so we need better debugging tools such as this. The idea originally came from a build tool I created called teapot. I wanted to visualise the build graph, and all the build logs, and dependencies, etc. I think the same approach makes sense for concurrent systems in general.Process.detach(pid) already non-blocking? In my answer I got a bit confused between detach and daemonize - I thought it was the same but it's not. Process.detach creates a thread which waits on the child process. In a way, all child process is non-blocking. But even this thread, if you call join on it, it will block (but we support non-blocking Thread#join in the fiber scheduler). In the fiber scheduler interface, we introduced a new hook called process_wait which makes Process.wait yield to the event loop. In the io_uring implementation of the event gem, we use pidfd to wait on the process using the event loop, so it's pretty efficient and non-blocking. More efficient than creating a thread per child process. Regarding Process.daemonize you should avoid this kind of model (including, more generally, fork) and use Async::Container.HTTPS by default. You can see the full documentation here which explains how to use it, and some example site here. If you are using ActiveRecord, you might have issues as ActiveRecord only allows one connection per thread (which is problematic as the entire event loop runs on one thread). If you want to try a completely event driven database driver, you could consider db. Sequel also has some partial support for event-driven concurrency.Async do
endpoint.accept do |peer|
Async do
raise "Fail"
end
end
end
Async::Task#wait propagates the exception. For network servers, the above design isolations failures to the inner most "task per request". The server itself is generally robust.mmap buffers (3) no encoding and (4) page aligned (without trailing \0 chracter forced by Ruby). I did introduce some basic pack/unpack for binary data and it was 4x faster than String#unpack so it would be exciting for binary formats as performance could be a lot better.If you have any other questions feel free to add them below.
n. Your Question …
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe