digitalmars.D - Reactor, fiber scheduler and async in Ruby 3.0
- Jacob Carlborg (27/27) Dec 31 2020 In Ruby 3.0, support for reactor, fiber scheduler and async has been add...
- Adam D. Ruppe (19/24) Dec 31 2020 omg that's a really good idea.
- ikod (7/18) Dec 31 2020 Yes, this is how I implemented this in my event loop framework:
- James Blachly (5/8) Jan 02 2021 ...
- Jacob Carlborg (6/7) Jan 06 2021 Yes, it has not been updated in 1.5 years. I asked in Slack about the
- Dmitry Olshansky (9/17) Jan 18 2021 Mostly dead, yes, my spare time is very limited these days, so
- James Blachly (3/17) Jan 19 2021 Understandable, and thank you for what you have done; in particular,
- Jacob Carlborg (6/7) Jan 19 2021 Mecca has now been move to dlang-community group [1]. I intend to
- Imperatorn (2/9) Jan 19 2021 🍀
- James Blachly (2/13) Jan 19 2021 unicode-beer-glyph =)
In Ruby 3.0, support for reactor, fiber scheduler and async has been added. async seems to be implemented in library code. The existing IO related methods in the core/standard library has been updated to be fiber scheduler aware. That basically means that if there is no fiber scheduler set, the IO operations will be blocking. If a fiber scheduler has been set, they will instead be non-blocking. A lot of existing code and gems will just work without having to be adopted for async. Here's an example: require 'async' require 'net/http' require 'uri' Async do ["ruby", "rails", "async"].each do |topic| Async do Net::HTTP.get(URI "https://www.google.com/search?q=#{topic}") end end end IO#read and IO#write are two of the methods that have been made fiber scheduler aware. Net::HTTP#get uses these methods under the hood and therefore will be non-blocking inside the Async block. See [1] for more details. BTW, Zig uses the same idea with the underlying IO functions that can adopt and become non-blocking. https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/ -- /Jacob Carlborg
Dec 31 2020
On Thursday, 31 December 2020 at 14:53:52 UTC, Jacob Carlborg wrote:The existing IO related methods in the core/standard library has been updated to be fiber scheduler aware. That basically means that if there is no fiber scheduler set, the IO operations will be blocking. If a fiber scheduler has been set, they will instead be non-blocking.omg that's a really good idea. Over the weekend I wrote a Phobos subclass <http://dpldocs.info/experimental-docs/arsd.fibersocket.html> that does fiber sockets. Pretty simple code really. But the connect* family of functions just assert they are inside a fiber right now.... but since they implement the same Socket interface, I could just do `if(fiber.getThis is null) return new Socket; else return new FiberSocket` and do the same behavior ruby is showing. Very convenient... (the difference between this and ruby though is i still have a FiberManager class you use as the socket factory, whereas I suppose they just made the existing methods return appropriate classes. Or heck I could even just make the overridden methods be like `if(thisFiber is null) super.receive(); else { ... }`. That'd be reasonably acceptable too. Heck even Phobos itself could potentially do that.)
Dec 31 2020
On Thursday, 31 December 2020 at 16:32:17 UTC, Adam D. Ruppe wrote:On Thursday, 31 December 2020 at 14:53:52 UTC, Jacob Carlborg wrote:Yes, this is how I implemented this in my event loop framework: https://github.com/ikod/hio/blob/master/source/hio/socket/package.d#L1275 Then your application can just ignore details of underlying socket implementation (it can be std.socket or unblocking sockets with event loop)The existing IO related methods in the core/standard library has been updated to be fiber scheduler aware. That basically means that if there is no fiber scheduler set, the IO operations will be blocking. If a fiber scheduler has been set, they will instead be non-blocking.omg that's a really good idea. Over the weekend I wrote a Phobos subclass <http://dpldocs.info/experimental-docs/arsd.fibersocket.html> that does fiber sockets. Pretty simple code really.
Dec 31 2020
On 12/31/20 9:53 AM, Jacob Carlborg wrote:In Ruby 3.0, support for reactor, fiber scheduler and async has been added. async seems to be implemented in library code. The existing IO related... Marginally on-topic: Is Photon dead? I understand Weka are no longer updating Mecca, yes?
Jan 02 2021
On 2021-01-03 03:50, James Blachly wrote:I understand Weka are no longer updating Mecca, yes?Yes, it has not been updated in 1.5 years. I asked in Slack about the future plans, I got this answer: "There's no formal answer to that, yet. I'll try and find out". -- /Jacob Carlborg
Jan 06 2021
On Sunday, 3 January 2021 at 02:50:27 UTC, James Blachly wrote:On 12/31/20 9:53 AM, Jacob Carlborg wrote:[snip]In Ruby 3.0, support for reactor, fiber scheduler and async has been added. async seems to be implemented in library code. The existing IO relatedMarginally on-topic: Is Photon dead?Mostly dead, yes, my spare time is very limited these days, so not doing much of anything in the D world. The biggest issue in reviving say Photon is the fact that I do not have a good project in mind to benefit from the infrastructure code of Photon. — Dmitry Olshansky
Jan 18 2021
On 1/18/21 2:21 PM, Dmitry Olshansky wrote:On Sunday, 3 January 2021 at 02:50:27 UTC, James Blachly wrote:Understandable, and thank you for what you have done; in particular, showing what is possible.Marginally on-topic: Is Photon dead?Mostly dead, yes, my spare time is very limited these days, so not doing much of anything in the D world. The biggest issue in reviving say Photon is the fact that I do not have a good project in mind to benefit from the infrastructure code of Photon. — Dmitry Olshansky
Jan 19 2021
On Sunday, 3 January 2021 at 02:50:27 UTC, James Blachly wrote:I understand Weka are no longer updating Mecca, yes?Mecca has now been move to dlang-community group [1]. I intend to at least make sure it works with the latest compilers. [1] https://github.com/dlang-community/mecca -- /Jacob Carlborg
Jan 19 2021
On Tuesday, 19 January 2021 at 15:26:34 UTC, Jacob Carlborg wrote:On Sunday, 3 January 2021 at 02:50:27 UTC, James Blachly wrote:🍀I understand Weka are no longer updating Mecca, yes?Mecca has now been move to dlang-community group [1]. I intend to at least make sure it works with the latest compilers. [1] https://github.com/dlang-community/mecca -- /Jacob Carlborg
Jan 19 2021
On 1/19/21 10:26 AM, Jacob Carlborg wrote:On Sunday, 3 January 2021 at 02:50:27 UTC, James Blachly wrote:unicode-beer-glyph =)I understand Weka are no longer updating Mecca, yes?Mecca has now been move to dlang-community group [1]. I intend to at least make sure it works with the latest compilers. [1] https://github.com/dlang-community/mecca -- /Jacob Carlborg
Jan 19 2021