Blocking consumer queue silent offer

[franz1981]

It would be nice to expose some "silent" version of offers that won't try to awake the consumer (it can both fail fast or just offer the element if not full): it can be beneficial when producers know upfront the offer batch size forcing to awake consumer just with a final "noisy" offer or delegating it to other producers that can sustain it. A "silent" fill can work too.
[OPTIONAL] In addition would be nice to expose some mechanism to awake the consumer without offering anything, to perform thread awaking on a separate thread that can sustain the awaking cost.

[franz1981]

Wdyt @nitsanw ? Do you think is a valid/interesting use case?

[nitsanw]

We are looking at 3 distinct API additions:

• ‘wakeup’ / ‘await’ which allow notifications
• ‘sneakyOffer’
• ‘sneakyFill’

We already have a ‘fill’ that serves as a notification at the end of the batch. I see a conflict here between ‘take’ and ‘wakeup’ that can be confusing.

[franz1981]

I like the "sneaky*" name, nice one!

I see a conflict here between ‘take’ and ‘wakeup’ that can be confusing.

You mean re the words meaning?

[nitsanw]

I mean that it's not clear how to return from take on wakeup. take should never return null, and the thread has not really been interrupted.

[franz1981]

Ah, you're right,I gotta refresh how the unblock thing work but I was thinking more about a wakeup-if-not-empty semantic (not sure is feasible) Il sab 8 mag 2021, 16:04 Nitsan Wakart ***@***.***> ha scritto:

…

I mean that it's not clear how to return from take on wakeup. take should never return null, and the thread has not really been interrupted. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#349 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEENMZO2FXYN5AT3XJX723TMVAIXANCNFSM44JF4CAQ> .