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 
> 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.

Reply via email to