Usos avanzados de los canales de Go

Extracto de la transcripción automática del vídeo realizada por YouTube.

so I'm going to start with asking a quick question as anybody actually read this book in this room very good okay the five of you put your hands up I allowed my hand to that and I had the misfortune or fortune to go to Oxford and Tony Hall was the professor

of computer science and so everything was either ml or CSP and I can answer Rob's question about where channels came from they are actually in this paper in 1979 towards a theory of communicating sequential processes which comes after the 78 paper and

this is it actually says we're going to have this problem with these processes talking to each other the technique we'll have is a channel and the only real difference with what's in go is that and there is a small thing in here which is there's

a channel generating process where you go get a channel from if you need a new channel but that that's where they come from now CSP is actually kind of an interesting thing in that everybody talks about it but nobody seems to quite know what it is there's

a really important thing in CSP which is that fundamentally if you look at it communication and synchronization us are the same thing in the original CSP there's no buffering and if things need to communicate they actually have to synchronize on something

that's happening and Tony Hoare was I think obsessed with chocolate vending machines we did actually have a chocolate vending machine in the program research group and almost all the introduction examples like this one process here is a vending machine

and it can do a coin it can participate in participation that's importantly a coin event and then it can participate in a chocolate event and then true to the one in the program research group it then breaks that's what stopped does and then a human

and kin who is are they going to pay by coin or in a slightly updated version card and can either put money in or try to use a card and then stop and the vending machines or the interaction of these two things is by synchronization and the communication here

is the coin so a vending machine and a person get together and they agree on participating in a coin event and and at that point the communication has happened the vending machine now knows there's money in it and chocolate comes out and there's no

notion here of channels in the original thing so it was all about this communication thing it's completely impractical to program like this and maybe complete nightmare without any sort of communication so of course we get we get channels and then so in

this talk I'm going to talk I'm going to stop talking about CSP but I do the book is worth reading because it covers a lot of implementations and it did anybody is anybody other than me programmed in Arkham here okay we can have like a support group

or something afterwards so ochem had very specific very very similar syntax for for channel communication so in go this is nice we see is this going to work we go there's this nice idea in of channels right which is these communications and just like in

CSP they are essentially there by direction where you can communicate in either direction there's an agreement between two two processes to communicate and so if you're not familiar this is how many people here are relatively new go programmers I'm

kind of curious about okay great so some of this is quite introductory and some of it is it gets more and more complicated we'll see how far I get so obviously sending and receiving on channels and you can also find out if a channel is closed or not which

turns out to be quite useful for quite a number of situations and the fundamental thing is there's an agreement and in general this is really displaying my CSP background i'm b'fer channels are mostly best and the reason they're mostly best

is they make reasoning about things simple because you know that if this guy and this guy are communicating they're doing it right now and there's no ambiguity about it and there's no race is happening and Sinti things so you can it makes it dead

easy and this is and one of the beautiful things about sequential programming like this with with concurrency is that it's actually really easy to reason about if you have these synchronization points it's just not hard you can easily look at piece

of programming and go oh is what's happening for example this silly little example I have here and there's a there's a something which thinks of a random number and there's something that receives that that number on a channel two completely

separate processes these would be processing the CSP perspective but you know that those things at that moment those two things agreed on on that anything happening and so for from a communication page of that you know if you're going to use do things

don't get tempted I think it's quite tempted to go how much buffering should I have in this channel the answer is zero unless you have a really good reason to do it and there are good reasons so one of them to do things about the fact that it's

communication ants organization at the same time is that turns out the channels are quite used to do SFIL without actually sending any data for just signaling things that happen so sometimes it's good enough just to wait for a channel to be closed so if

you want to wait for something to happen so in this example I've got a go routine it's going to do something and it's going to close a channel and then some other thing maybe it's the main or some other go routine just sits and waits for that

[ ... ]

Nota: se han omitido las otras 2.770 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.