Yup I thin I was frying my brain on this - it also led to questions such as
"if I read a worker from the channel and there ISNT a URL waiting how do I
write back into the channel making it available - what if more than one go
routine is reading from the channel... etc"
I knew I was over complicating it I just couldnt see the forest for the
trees! I assumed I wanted channels for the available and busy workers when
really I wanted stacks.
thanks for the in-depth discussion - in future I will sleep on it next time
and come at it afresh :)
(ironically I'd done exactly this before with stacks in an old project
which is what gave me the lightbulb moment this morning)
Thanks everyone!
On Thursday, December 1, 2016 at 3:21:46 PM UTC, Jesper Louis Andersen
wrote:
>
> On Wed, Nov 30, 2016 at 6:07 PM <omarsharif...@gmail.com <javascript:>>
> wrote:
>
>> Hi, I'm having a bit of a slow day... I'm trying to synchronise two reads
>> from two channels and can't get my fuzzy head round the problem.
>>
>>
> Go doesn't have support for an (atomic) read from multiple channels at
> once. There are other systems which can do this (JoCaml, join-calculus,
> Concurrent ML, Haskell's STM, Reagents[0] in Scala, ...)
>
> However, as you found out, one can often rearrange the code base as to
> avoid the problem. There is also the problem of more advanced
> select-constructs not being free in the performance sense: atomic sync on
> multiple channels tend to be rather expensive.
>
> One reason it isn't that simple to implement is to consider the following
> (hypothetical) snippet:
>
> select {
> case w := <-available && urlChan <- value:
> ..BODY..
> }
> }
>
> in which the atomic operation must simultaneously receive a message on the
> 'available' channel and send a message on the 'urlChan' channel. And
> further, since you introduced && to mean logical-and-between-channels, you
> might as well introduce || to mean logical-or-between-channels. Once there,
> you may want to introduce a new type
>
> event t
>
> for some type t alongside 'chan t'. Hence the expression (<-available)
> becomes an expression of type 'event *worker' and now they can be composed
> via && and ||. This means we can get rid of select since it is just an
> expression which successively applies || to a slice of values. If we then
> introduce an new statement, sync, which turns 'event t' into a 't', we are
> done. And we have almost implemented the basis of Concurrent ML in the
> process.
>
> In short, you could be opening a regular can of worms if you start
> allowing for more complicated select-expressions. Hence the school of
> keeping them relatively simple.
>
> [0] https://people.mpi-sws.org/~turon/reagents.pdf
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
