3 ms·

It worth remembering that ruby code already handles async, and threads. For example ActiveRecord database requests have been non-blocking for many years. This

by Lio 6y ago

It worth remembering that ruby code already handles async, and threads. For example ActiveRecord database requests have been non-blocking for many years. This new scheduler interface just gives us a nicer and lighter weight abstraction for handling it rather than, for example, using OS thread.

jashmatthews 6y ago
> ActiveRecord database requests have been non-blocking for many years. That's blocking IO with multi-threading. The executing thread stops and waits.
- Lio 6y ago
  Yes, poor choice of words on my part. The IO calls themselves still block but each is in its own OS thread and GVL releases when the thread blocks. If you can only do parallel IO in a thread why not use a light weight fibre (green thread) instead of an OS thread? Hence this new scheduler and fibres.
  - jashmatthews 6y ago
    > each is in its own OS thread and GVL releases when the thread blocks. The GVL isn't automatically released when a thread blocks on IO. Each bit of native code performing IO has to explicitly release it like in the pg gem here: https://github.com/ged/ruby-pg/blob/fb465855ce1dd12cf7eb69c92af222052aa956ce/ext/gvl_wrappers.h#L4 https://github.com/ged/ruby-pg/blob/fb465855ce1dd12cf7eb69c9... If you don't need high concurrency then using threads is simpler.
adrianpike 6y ago
> For example ActiveRecord database requests have been non-blocking for many years. Right, but it still blocks the entire calling thread, no? Been a few years since I've been deep into Rails.
- Lio 6y ago
  Ah, I see the confusion in what I’ve said. Yes the IO calls themselves are blocking but you can easily wrap them in separate OS threads. The GVL will release when the IO call blocks allowing another OS thread, including the parent, to continue. That allows you to make blocking calls in parallel but is heavier weight than using the new scheduler and fibres for those parallel IO calls. In the case of ActiveRecord I think it’s down to the database driver implementation, anyone who knows care to comment?

by Lio 6y ago

jashmatthews 6y ago

> ActiveRecord database requests have been non-blocking for many years. That's blocking IO with multi-threading. The executing thread stops and waits.

Lio 6y ago
Yes, poor choice of words on my part. The IO calls themselves still block but each is in its own OS thread and GVL releases when the thread blocks. If you can only do parallel IO in a thread why not use a light weight fibre (green thread) instead of an OS thread? Hence this new scheduler and fibres.
- jashmatthews 6y ago
  > each is in its own OS thread and GVL releases when the thread blocks. The GVL isn't automatically released when a thread blocks on IO. Each bit of native code performing IO has to explicitly release it like in the pg gem here: https://github.com/ged/ruby-pg/blob/fb465855ce1dd12cf7eb69c92af222052aa956ce/ext/gvl_wrappers.h#L4 https://github.com/ged/ruby-pg/blob/fb465855ce1dd12cf7eb69c9... If you don't need high concurrency then using threads is simpler.

adrianpike 6y ago

> For example ActiveRecord database requests have been non-blocking for many years. Right, but it still blocks the entire calling thread, no? Been a few years since I've been deep into Rails.

Lio 6y ago
Ah, I see the confusion in what I’ve said. Yes the IO calls themselves are blocking but you can easily wrap them in separate OS threads. The GVL will release when the IO call blocks allowing another OS thread, including the parent, to continue. That allows you to make blocking calls in parallel but is heavier weight than using the new scheduler and fibres for those parallel IO calls. In the case of ActiveRecord I think it’s down to the database driver implementation, anyone who knows care to comment?