I think the point is to not generate values by producer if external
service is not available
The producer only unparks when the value is effectively consumed by
the external service. That's my objective.
external ready channel here serves as a latch that stops producer
generating value.
On Thu,
Hi Nahuel,
I think it's worth stepping back from discussing solutions and have a look
at the problem. If I'm reading things right you need the following:
1. Producer produces values one at a time - should not step until last
value has been handled correctly elsewhere.
2. Middleman needs to
Fluid: as you said, backpressure on the outgoing channel will be sufficient
to avoid producer to overrun consumer (without using any extra
ack-channel), but the producer will compute a new not-yet-used value before
blocking on sending it to consumer. That's what I want to avoid.
I can also use
Hi Nahuel,
Thanks for the clarification. Multiple producers, single middleman is a
different problem from the one we (or at least I) thought we were dealing
with. In that case, the put your ack channel in your product, block on the
ack channel method is the right one.
(loop [...]
..something
Fergal: I knew about the ack channel solution (note I mentioned it a while
couple of mails ago), I was trying to avoid it with the objective of making
the producer code extra simple.
Also note, in core.async the producers aren't totally decoupled from
consumers, there is an implicit
Hi Nahuel,
If you look at the definition of simple it means not compound. In your
case, you are trying to have a single thing (the channel) do two jobs:
convey the value, and control the producer. This is not simple, and makes
the producer trust that the middleman will always respect this hidden
Fergal: readability when using an ack channel is improved, you are totally
right on this point and is probably the most important argument for using
acks, besides there is no peek currently on core.async (note if you have a
long producer-consumer1-consumerN chain everyone must implement the ack
On Thursday, October 9, 2014 2:22:50 PM UTC+2, Nahuel Greco wrote:
Fluid: as you said, backpressure on the outgoing channel will be
sufficient to avoid producer to overrun consumer (without using any extra
ack-channel), but the producer will compute a new not-yet-used value before
blocking
Leon: your :useless example is equivalent to one using the hypothetical
peek operation and to the ack-channel solution, but what you define as
:useless multithreading because at one time only one thread is working,
is a valid synchronization scenario and the one I was searching for. The
objective
On Thursday, October 9, 2014 10:25:38 PM UTC+2, Nahuel Greco wrote:
Leon: your :useless example is equivalent to one using the hypothetical
peek operation and to the ack-channel solution, but what you define as
:useless multithreading because at one time only one thread is working,
is a
On Monday, October 6, 2014 9:36:59 AM UTC-4, edbond wrote:
Add one more chan, external ready.
Put :ok there to let producer generate new value.
producer:
- read from external ready
- generate value
- put into outgoing chan
client:
- contact external server, put in external ready if ok
Add one more chan, external ready.
Put :ok there to let producer generate new value.
producer:
- read from external ready
- generate value
- put into outgoing chan
client:
- contact external server, put in external ready if ok
- read from outgoing chan
- send to external
Handle exceptions and
On Sunday, October 5, 2014 12:51:04 AM UTC-4, Nahuel Greco wrote:
I was thinking in a single-consumer scenario with a buffered chan, in
which you want to check if you can consume the value before effectively
consuming it. As you said, a peek operation has no sense if the channel has
Picture the following:
producer --- go-loop --- external service
1- The producer puts a value to a unbuffered (chan) by doing (! c v)
2- The go-loop consumes the value with a take operation, **unblocking** the
producer
3- The go-loop contacts the external-service but the external service
answers
I think you can achieve an effect similar to what you want by using a pub
with an appropriate topic function that classifies the input in some way,
and then subscribing to the topic whose value you want to see. This also
has the benefit of automatically 'mult'ing the channel input, so you can
Adrian: I don't see how a pub can help here, in the previous example to
consume or not the value was decided not on some property intrinsic to the
value (one you can create a topic from), but on the result of sending it to
an external service.
Saludos,
Nahuel Greco.
On Sun, Oct 5, 2014 at 12:59
Then how would peeking at the value help?
On Sunday, October 5, 2014 12:14:32 PM UTC-4, Nahuel Greco wrote:
Adrian: I don't see how a pub can help here, in the previous example to
consume or not the value was decided not on some property intrinsic to the
value (one you can create a topic
previous example with the peek operation:
1- The producer puts a value to a unbuffered (chan) by doing (! c v)
2- The go-loop unparks from (peek! c) without consuming the value, the
producer keeps parked
3- The go-loop contacts the external-service
4-A If the external-service answer is ok, the
Ah, I think we're on the same page now. I've come across the need for this
recently in some code for a UDP based protocol between a multiplayer game
client and server.
I still think a pub fits in here nicely. You can consume the value from the
channel in question and park until you get an
You can do that without a pub, the producer can send a new (chan) inside
the request to the go-loop and the go-loop will ack on that chan when
getting a good response from the external service.
That schema solves this scenario, I mentioned it in the previous mail, but
I think a peek operation
Yes, but the advantage of using a pub is that it's simpler to have one
input channel than to continually spawning new ones. But that's just my
opinion. Anyway, sorry I couldn't be more help.
On Sunday, October 5, 2014 1:04:58 PM UTC-4, Nahuel Greco wrote:
You can do that without a pub, the
On Sunday, October 5, 2014 5:33:16 PM UTC+2, Nahuel Greco wrote:
Picture the following:
producer --- go-loop --- external service
1- The producer puts a value to a unbuffered (chan) by doing (! c v)
2- The go-loop consumes the value with a take operation, **unblocking**
the producer
3-
I think you should go for the ack solution. What is your reservation about
it?
On Sunday, 5 October 2014, Leon Grapenthin grapenthinl...@gmail.com wrote:
On Sunday, October 5, 2014 5:33:16 PM UTC+2, Nahuel Greco wrote:
Picture the following:
producer --- go-loop --- external service
1-
Maybe not, maybe you want to reserve the cpu cycles for other tasks, or the
producer needs a confirmation for other purposes before computing or
requesting the value from another party. This is a simplified and distilled
scenario.
El 05/10/2014 16:55, Leon Grapenthin grapenthinl...@gmail.com
No reservation, the ack solution works, but 1- I think the producer code
can be simplified with the peek operation and 2- I want to know is there is
a fudamental limitation in chans design/implementation prohibiting adding a
peek operation.
El 05/10/2014 17:03, Gary Verhaegen
On Sunday, October 5, 2014 10:14:19 PM UTC+2, Nahuel Greco wrote:
Maybe not, maybe you want to reserve the cpu cycles for other tasks, or
the producer needs a confirmation for other purposes before computing or
requesting the value from another party. This is a simplified and distilled
Why would you want this? To leave the value inside the channel for other
consumers?
In that case there would be no guarantee that the value returned by the
peek operation is the next value in the channel, because it might have been
consumed already.
Best regards, Leon
On Monday, September
I was thinking in a single-consumer scenario with a buffered chan, in which
you want to check if you can consume the value before effectively consuming
it. As you said, a peek operation has no sense if the channel has multiple
consumers.
Saludos,
Nahuel Greco.
On Sat, Oct 4, 2014 at 9:17 PM,
Currently if you block/park on a channel reading it by using !!/! or
alts!/alts!! the value will be consumed when it appears, so there is no way
to block/park waiting a new value without removing it from the channel.
There is a non-consuming peek operation planned in the core.async roadmap
or a
29 matches
Mail list logo
