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

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

[phigrofi]

Issue #18814 has been reported by phigrofi (Philipp Großelfinger).

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

* Author: phigrofi (Philipp Großelfinger)
* Status: Open
* Priority: Normal
----------------------------------------
## Abstract
  A simple method to query the current size of a Ractor's incoming queue from outside. Can be used to decide on the sender's side if a message is sent or postponed. 

## Background
  Ractors have an infinite incoming message queue. When messages are sent to 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 accept each message and put them into a separate queue and keep track of their count. Then the sending Ractor could query the count from the receiving Ractor as a message. 
While this message exchange would be short and simple, it still requires the receiving Ractor to process the "queue-count" message and respond to it. 

## Proposal
  The Ractor implementation already keeps track of the current incoming message 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 query the queue size from outside. This works without any interaction of the queried Ractor. 

The code would work as follows:
``` ruby
ractor = Ractor.new do
  loop { sleep(1) }
end
ractor.queue_size #=> 0
ractor << "message"
ractor.queue_size #=> 1
ractor << "message"
ractor.queue_size #=> 2
```


## Use cases
  1. Avoid queue overflow by checking queue size from outside before sending further messages. 
  2. Incoming queue sizes can be monitored. 

## 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 to communicated, ignores the concept of a Ractor's incoming message queue and makes it quite complicated. 

## See also
  In this [issue](https://bugs.ruby-lang.org/issues/17679) a middleman solution was proposed which keeps track of a separate queue count. 



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

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

[phigrofi]

Issue #18814 has been updated by phigrofi (Philipp Großelfinger).


For instance in GO it is possible to query to current size of a channel: 

``` go
c := make(chan int, 100)
for i := 0; i < 34; i++ {
  c <- 0
}
fmt.Println(len(c)) // => 34
```


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

* Author: phigrofi (Philipp Großelfinger)
* Status: Open
* Priority: Normal
----------------------------------------
## Abstract
  A simple method to query the current size of a Ractor's incoming queue from outside. Can be used to decide on the sender's side if a message is sent or postponed. 

## Background
  Ractors have an infinite incoming message queue. When messages are sent to 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 accept each message and put them into a separate queue and keep track of their count. Then the sending Ractor could query the count from the receiving Ractor as a message. 
While this message exchange would be short and simple, it still requires the receiving Ractor to process the "queue-count" message and respond to it. 

## Proposal
  The Ractor implementation already keeps track of the current incoming message 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 query the queue size from outside. This works without any interaction of the queried Ractor. 

The code would work as follows:
``` ruby
ractor = Ractor.new do
  loop { sleep(1) }
end
ractor.queue_size #=> 0
ractor << "message"
ractor.queue_size #=> 1
ractor << "message"
ractor.queue_size #=> 2
```


## Use cases
  1. Avoid queue overflow by checking queue size from outside before sending further messages. 
  2. Incoming queue sizes can be monitored. 

## 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 to communicated, ignores the concept of a Ractor's incoming message queue and makes it quite complicated. 

## See also
  In this [issue](https://bugs.ruby-lang.org/issues/17679) a middleman solution was proposed which keeps track of a separate queue count. 



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

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

[phigrofi]

Issue #18814 has been updated by phigrofi (Philipp Großelfinger).



I created a PR for this issue: https://github.com/ruby/ruby/pull/5973

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

* Author: phigrofi (Philipp Großelfinger)
* Status: Open
* Priority: Normal
----------------------------------------
## Abstract
  A simple method to query the current size of a Ractor's incoming queue from outside. Can be used to decide on the sender's side if a message is sent or postponed. 

## Background
  Ractors have an infinite incoming message queue. When messages are sent to 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 accept each message and put them into a separate queue and keep track of their count. Then the sending Ractor could query the count from the receiving Ractor as a message. 
While this message exchange would be short and simple, it still requires the receiving Ractor to process the "queue-count" message and respond to it. 

## Proposal
  The Ractor implementation already keeps track of the current incoming message 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 query the queue size from outside. This works without any interaction of the queried Ractor. 

The code would work as follows:
``` ruby
ractor = Ractor.new do
  loop { sleep(1) }
end
ractor.queue_size #=> 0
ractor << "message"
ractor.queue_size #=> 1
ractor << "message"
ractor.queue_size #=> 2
```


## Use cases
  1. Avoid queue overflow by checking queue size from outside before sending further messages. 
  2. Incoming queue sizes can be monitored. 

## 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 to communicated, ignores the concept of a Ractor's incoming message queue and makes it quite complicated. 

## See also
  In this [issue](https://bugs.ruby-lang.org/issues/17679) a middleman solution was proposed which keeps track of a separate queue count. 



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

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

[shyouhei (Shyouhei Urabe) via ruby-core]

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





I heard from @ko1 in person that _he_ doesn't need this feature to implement his ractor pool.  From what I understand he would have a single ruby-level Queue instance for all incoming messages and instead of pushing those messages 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 reason why golang's `len()` is not a good idea.



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

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

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



* Author: phigrofi (Philipp Großelfinger)

* Status: Open

* Priority: Normal

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

## Abstract

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



## Background

  Ractors have an infinite incoming message queue. When messages are sent to 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 accept each message and put them into a separate queue and keep track of their count. Then the sending Ractor could query the count from the receiving Ractor as a message. 

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



## Proposal

  The Ractor implementation already keeps track of the current incoming message 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 query the queue size from outside. This works without any interaction of the queried Ractor. 



The code would work as follows:

``` ruby

ractor = Ractor.new do

  loop { sleep(1) }

end

ractor.queue_size #=> 0

ractor << "message"

ractor.queue_size #=> 1

ractor << "message"

ractor.queue_size #=> 2

```





## Use cases

  1. Avoid queue overflow by checking queue size from outside before sending further messages. 

  2. Incoming queue sizes can be monitored. 



## 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 to communicated, ignores the concept of a Ractor's incoming message queue and makes it quite complicated. 



## See also

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







-- 

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

 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

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

[hsbt (Hiroshi SHIBATA) via ruby-core]

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 
https://bugs.ruby-lang.org/issues/18814#change-109874

* Author: phigrofi (Philipp Großelfinger)
* Status: Assigned
* Assignee: ko1 (Koichi Sasada)
----------------------------------------
## Abstract
  A simple method to query the current size of a Ractor's incoming queue from outside. Can be used to decide on the sender's side if a message is sent or postponed. 

## Background
  Ractors have an infinite incoming message queue. When messages are sent to 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 accept each message and put them into a separate queue and keep track of their count. Then the sending Ractor could query the count from the receiving Ractor as a message. 
While this message exchange would be short and simple, it still requires the receiving Ractor to process the "queue-count" message and respond to it. 

## Proposal
  The Ractor implementation already keeps track of the current incoming message 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 query the queue size from outside. This works without any interaction of the queried Ractor. 

The code would work as follows:
``` ruby
ractor = Ractor.new do
  loop { sleep(1) }
end
ractor.queue_size #=> 0
ractor << "message"
ractor.queue_size #=> 1
ractor << "message"
ractor.queue_size #=> 2
```


## Use cases
  1. Avoid queue overflow by checking queue size from outside before sending further messages. 
  2. Incoming queue sizes can be monitored. 

## 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 to communicated, ignores the concept of a Ractor's incoming message queue and makes it quite complicated. 

## See also
  In this [issue](https://bugs.ruby-lang.org/issues/17679) a middleman solution was proposed which keeps track of a separate queue count. 



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/