[ruby-core:111668] [Ruby master Feature#18814] Ractor: add method to query incoming message queue size

Issue #18814 has been updated by shyouhei (Shyouhei Urabe).





I heard from @ko1 in person that _he_ doesn't need this feature to implemen=
t his ractor pool.  From what I understand he would have a single ruby-leve=
l Queue instance for all incoming messages and instead of pushing those mes=
sages to each ractors one by one, he would let everyone pull messages from =
that queue at once.



But I might have missed his details. @ko1 please explain your detailed reas=
on why golang's `len()` is not a good idea.



----------------------------------------

Feature #18814: Ractor: add method to query incoming message queue size=20

https://bugs.ruby-lang.org/issues/18814#change-101060



* Author: phigrofi (Philipp Gro=DFelfinger)

* Status: Open

* Priority: Normal

----------------------------------------

## Abstract

  A simple method to query the current size of a Ractor's incoming queue fr=
om outside. Can be used to decide on the sender's side if a message is sent=
 or postponed.=20



## Background

  Ractors have an infinite incoming message queue. When messages are sent t=
o a Ractor it is not possible to check the current count of elements in the=
 queue. A workaround would be: The receiving Ractor could immediately accep=
t each message and put them into a separate queue and keep track of their c=
ount. Then the sending Ractor could query the count from the receiving Ract=
or as a message.=20

While this message exchange would be short and simple, it still requires th=
e receiving Ractor to process the "queue-count" message and respond to it. =




## Proposal

  The Ractor implementation already keeps track of the current incoming mes=
sage fill level in the field `sync.incoming_queue.cnt`. A simple method in =
the ruby code of Ractor could expose this number so that it is simple to qu=
ery the queue size from outside. This works without any interaction of the =
queried Ractor.=20



The code would work as follows:

``` ruby

ractor =3D Ractor.new do

  loop { sleep(1) }

end

ractor.queue_size #=3D> 0

ractor << "message"

ractor.queue_size #=3D> 1

ractor << "message"

ractor.queue_size #=3D> 2

```





## Use cases

  1. Avoid queue overflow by checking queue size from outside before sendin=
g further messages.=20

  2. Incoming queue sizes can be monitored.=20



## Discussion

  The proposal makes it much easier to prevent overflow of a message queue =
than managing a separate queue inside of a Ractor and keeping track of its =
element count. I think also having a separate queue where the count needs t=
o communicated, ignores the concept of a Ractor's incoming message queue an=
d makes it quite complicated.=20



## See also

  In this [issue](https://bugs.ruby-lang.org/issues/17679) a middleman solu=
tion was proposed which keeps track of a separate queue count.=20







--=20

https://bugs.ruby-lang.org/

 ______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-c=
ore.ml.ruby-lang.org/