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

Issue #18814 has been updated by hsbt (Hiroshi SHIBATA).

Status changed from Open to Assigned
Assignee set to ko1 (Koichi Sasada)

----------------------------------------
Feature #18814: Ractor: add method to query incoming message queue size=20
https://bugs.ruby-lang.org/issues/18814#change-109874

* Author: phigrofi (Philipp Gro=DFelfinger)
* Status: Assigned
* Assignee: ko1 (Koichi Sasada)
----------------------------------------
## 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/lists/ruby-core.ml.rub=
y-lang.org/