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

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.)

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:
>> 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.

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)

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?

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

On Sunday, 3 January 2021 at 02:50:27 UTC, James Blachly wrote:
> 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
[snip]

> 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

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

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

🍀

On 1/19/21 10:26 AM, 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

unicode-beer-glyph =)

On 1/18/21 2:21 PM, Dmitry Olshansky wrote:
> On Sunday, 3 January 2021 at 02:50:27 UTC, James Blachly wrote:
>> 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

Understandable, and thank you for what you have done; in particular, showing what is possible.