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,
>
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 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
> bloc
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
pro
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 hidd
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 consumer->prod
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 expe
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 alt
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 consum
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 Th
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 "exter
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 excepti
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
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" escribió:
> I thi
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" escribió:
>
>
> On Sunday,
I think you should go for the ack solution. What is your reservation about
it?
On Sunday, 5 October 2014, Leon Grapenthin wrote:
>
>
> On Sunday, October 5, 2014 5:33:16 PM UTC+2, Nahuel Greco wrote:
>>
>> Picture the following:
>>
>> producer ---> go-loop ---> external service
>>
>> 1- The prod
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 pr
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
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 maybe
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 ackn
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 wrote:
> 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
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 topi
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
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
h
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
answe
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
> mu
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, Leon
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 29
28 matches
Mail list logo
