Transcript for:
Asynchronous I/O Library (Asio)

about um costco really so the asynchronous io library uh the whole flash xml thing um came up very similar to why the spirit discussion came up yesterday um spending time on irc um i started using the assistant bio library some time ago and um really liked it a lot got rid of all my own stuff converted to that people were asking questions on irc nobody was ever answering them and i thought huh one way to learn is just start answering questions so a lot of this presentation comes from what i've learned from helping people on irc with um with the ac press i o library which again means it's a pretty tutorial uh like for a for a presentation so let's get started um he's looking at this i o library this library started off as a network library that was the intent and it's kind of grown from there it uses a pro proactor model which we talk about and what that means um but in essence it's a very efficient way to handle lots of things going on at once and so we want to be able to handle lots and lots of connections it grew from that it's not it doesn't just handle um network activity anymore it's got serial ports job descriptors timers it's got it's got all kinds of things the library is large um and the reference though is very good so if you're going to start with the uh asynchronous i like i o library um i recommend reading the first part the overview that everybody always skips because it has all of the nuggets that are really important in it so if we miss them here we'll get in there yes um is it excuse me it's still in blue it is primarily header though there can be a dependency on um thread and on system um so those you'll need to link but let's not worry about that for me all right what is asynchronous um io so i i have a number of kids my oldest two daughters are great um i work from my home office i say hey i'd like to have a coffee and um my old star says great and she runs on down and she um she begins to make my cappuccino i sit there and i continue to work and i get stuff done eventually she comes upstairs she hands me my coffee i say thank you that was an asynchronous transaction very excited right i got a bunch of work done i just made a request for a coffee and then the coffee came in my third daughter loves to make coffee for me but the problem is is she needs supervision she needs a type of supervision where um i watch her make the coffee because that's the fun part is making the coffee and so i'm not actually allowed to help in the coffee making process i'm just allowed to stand there and make sure it doesn't go awry along the process so the end result is i ask for a coffee she gets excited she wants to make me a coffee we both go downstairs we hang out at the machine she makes it work i sit there and wait she gives me my coffee i say thank you i go back upstairs i sit down that is not an asynchronous um type of mode to get coffee all right i sat there i made a request i sat there and i just waited for the thing to occur um oh it's anywhere you'd like marshall probably you have a um some function here called read file it takes a file name it takes a buffer and it takes a handler um to call when it's done it goes on so it starts the process of reading the file it doesn't wait for the file to get ripped it just starts that activity because it does some work and eventually the handler gets called saying it was done doing that now if you're thinking a bit at the moment you're going to say well wait i've started something someplace later likely in some other thread i'm going to get notified that it occurred this is going to sound like it's going to start getting a little complicated um and so you might ask um and at this point it's going to scare you for a little bit but i'm not going to do that or someone won't get to the end um sounds hard so why um so let's just think about maybe one of the reasons why we might want to do this so you have a server and you have a client and you're naive so if you're a naive and you have a server and a client connects you need to read data from it but you don't want to block reading data form from it you want to do something else also so what do you do you create a thread the thread is going to sit there and block on the read reed and potentially you want to write data back out depending upon how sophisticated you become you might want to create a right thread and a read thread for each or you might be a little smarter you realize you could have one right thread that's going to handle all your clients but they still each have to have a re-thread as you can see this is not going to scale very well for us we've got four clients we now have eight threads um and at some point you're going to become pretty unhappy if you're not your customer is somebody's going to get really unhappy with all the resources just sitting around doing nothing we would prefer something like this an asynchronous model we have lots of clients connecting but we're able to service all of them with one thread because think about it in the in this past slide what are we doing most of the time we're waiting right so we're just we're doing nothing we're wasting resources we're just kind of hanging out um all right um i'm not sure about you but for me um as hartman knows because i occasionally i'll tell him that my world view of spirit just got adjusted i have mental models of how things work it's not how it necessarily works but it's my mental model of how it works i'm just a user right and as long as that goes well in life i'm happy as soon as it breaks i'm just like the physicist who tries to figure out how to change my model slightly and then i have a new model of how the world works because i really don't care necessarily how it all works i just need the right model um this seems to be the hardest part with um the asynchronous side library if you're not familiar with a proactor model and you have never used one before um and you're coming at this without maybe visiting a reactor model either which would be like an ace and then then you're you need to get some adjustment and so how we're gonna get some adjustment is we're gonna have a story so reading slides is bad but reading stories is good so i'm gonna read you a story uh the story came about because my wife who is an art major said when i showed her my slides and i was very excited about beemer she said those are boring so we're um we're going to try to spice them up here so this is a pro actors story all right mom dad johnny and butler they go to the beach dad tells butler to wait at the slushy sash shack after some time dad and johnny go to get a slushie dad brings his own cup he is greeted by the owner i would like to order a slushie here is my cup please deliver to johnny when it is ready dad heads off to explore the beach johnny builds a sandcastle owner begins to make a slushie and butler waits owner starts the blender and goes back to take the next customer's order slushie's ready an owner moves the cup to the completion table where the assistant is waiting assistant gives the slushie to butler for delivery to johnny butler is happy to have something to do butler delivers the slushie to johnny he was happy too butler returns to the slushy shack and weights dad sometimes will order multiple slushies one for mom and one for johnny that isn't a problem assistant just gives the first one ready to butler butler can only deliver one at a time and returns for the second slushie other families come to the beach and bring their butlers in the slushy completion line this works well because it helps keep the assistant's slushy completion table empty assistant still remembers that fateful day when no butlers came to the beach there was also the time that each kid brought a butler disaster no room at the shack too busy yet nothing was getting done the families agreed that two butlers would be plenty for all now they share occasionally tragedy strikes johnny will leave to chase waves without getting this slushy butler will die of exhaustion trying to find him or somebody will take their cup and go home while the slushie is being made and it gets poured all over the floor yuck dad is sometimes very generous johnny would like an orange and one purple slushie if both slushies are done at the same time and both butlers are available then johnny gets two slushies at once this confuses johnny and causes brain freeze susie is smarter and doesn't mind if both slushies come at one time but most of the time the dads are making requests to the owner the assistant is monitoring the table the kids are building sandcastles and the butlers are just waiting all right let's go ahead and take a look sadly the proactor model is not as creative and they use very boring names so dad is called the initiator um the butler is is kind of the pro actor i've taken some liberty here and i'll tell you what that is here in a moment the asynchronous operation processor is the owner an asynchronous operation itself was the blender actually making decision asynchronous event demultiplexer is the assistant there's a completion event queue which was really our completion table and then there is a completion handler which was johnny we had some additional roles played today the operating system was basically the blender memory to be filled was the empty cup um the slushy was the stuff filled in so the um a full cup was the data in the memory um this is the very boring thing we would have normally drawn and i would have talked about for a long time but hopefully that story just told us all of the different relationships that exist um what i would like to mention here is where the asynchronous io library exists and where the rest of our stuff exists and so dad who was the initiate who's starting the asynchronous activity that's our application that's that's part of our our stuff um the completion handler that's part of our stuff the proactor notice we supplied the butler when we got to the beach the top half of that the thing that's going to deliver it is our part um the bottom part of the proactor actually belongs to the asynchronous io library and we'll talk about that in a little bit okay a few lessons hopefully from the story um everything that was happening with inside the slushy shack all activity all threads all anything that was going on in there is completely transparent to the families at the beach they don't really know they make requests and somehow through the butler which they supply they get the thing back but whatever else happened inside the shack they don't know about and they don't care about second the butler delivered the results and the butler was supplied by the family so the result didn't come from the shack or from the asynchronous library or from the proactor model the reason you got it was because you gave it something a thread to deliver it to you the cup was both supplied by the family it's owned by the family and if the family takes it away we're going to have problems um how many are familiar with the ace libraries and using that so the ace primarily i haven't used these for a really long time but primarily ace is a reactor system they have a proactor from my understanding now built on it one of the main difference between a reactor and a proactor is that um in the reactor you don't supply the cup you're told that the thing is done and then you supply the cut so you can see there's going to be some memory that we're going to be giving away it's going to be hanging out in the shack we're going to be having cups hanging out the shack until something's done and we get them back that could be considered a disadvantage of this model a few more some handlers like johnny don't like to have multiple things delivered at once um i think this is where i'm supposed to say use locks so um susie she doesn't care so susie uses locks johnny doesn't for whatever reason um you write the handler you own johnny if you make johnny so he can't handle multiple things being delivered then keep that in mind don't leave the beach your cup before you've gotten the stuff you're supposed to get um that's the same thing as having some um reference cult that isn't there anymore or a pointer that's being filled up with stuff that's been deleted it's a bad thing i'm sure you've all had bad things um it only takes a few butlers or a few threads to handle all requests that are going on in the system that's really one of the keys you don't you don't need a lot to service a lot of activity that's going on because io is slow that's the whole idea right you've made a request now you're just waiting around for it so instead of waiting you're gonna go do something exciting but somebody else is going to wait for you on the previous slide why don't we have a notion of cancellation so we can lose the um you can so if you cancelled the blender you could leave and that you tell the shack that you want to cancel the request and then what it does underneath there are some different different things that occur so yes you could do that you could cancel your order um most people don't especially if you're starting you're you're more likely to leave the beach without thinking about cancer and you'll probably do it on accident uh we'll talk about how you move around around that okay let's look at some examples we're gonna use timer at first um timer is one of the facilities that's inside the synchronous bio library but everybody understands the timer and this is gonna be really easy to breeze through and just start understanding some of the basics of this library all right so i've created a sum function called timer expired it takes an error code it's gonna print out timer expired inside of main i'm going to create this thing called the i o service this is the shack for all practical purposes okay the i o service is the pro actor it's also a bunch of the other bits but um think of it at the moment as the shack we'll refine our thoughts as we go but this is a good place to start um we're going to create a deadline timer a deadline timer um is going to eventually become a request it is the asynchronous thing that we want done um and we're going to eventually make a request on that astropinus thing to have it done asynchronously we the osteo library can do synchronous and asynchronous we're not going to talk about the synchronous stuff because it doesn't interest me at all so we're going to only talk about asynchronously um all right so we create this and we tell it that here is the shack so we tell it where the i o service is um and we we're giving it a timeout period this one is related to five seconds so um we have a deadline timer it's gonna expire in five seconds now i haven't started it yet we just we made one right so it's like it's like the uh the order tag we haven't given to anybody to make a request but we've got the tab um here we're going to start it so we say timer async weight and then we give it the handler we tell it who do we want you to tell this is johnny we want you to tell johnny when it's done so timer we're using the timer object and the async weight at this point we're making the request to begin the weight all right so for five seconds uh we're gonna just print out calling the i o service run here's the service run this is like supplying a bubbler all right you don't call run um remember cups line up on the table nothing gets done so this is the this is the thing that is going to call the handler and then we're going to have a printout done see what happens um okay uh if you go back one time uh when does the timer actually start or um yesterday i tried to anticipate everybody's questions and it's the very next little slide well that's pretty much the same question i just wanted to understand there's two commands in line 14 and 18. you said that the command starts in line 15 yep well you'll see in the next set and you everywhere assets but actually the operating systems are created to run the timeline there is no thread in this created um as far as your oh i don't know okay right we don't know we don't care this is part of the what occurs in the shack we don't care about because normally i i have to associate the sweat with also um so you know we will finish i think in our next set of slides it'll become a little more clear what's happening um and and then if not you let me know okay so what we have here um on the output calling i o service run uh right here calling ios service run timer expired this was our handler got called and then done done we'll talk about this later while we did the done so we're going to hold off on that all right here is same thing same timer but now we've got this little thing called now time um now time is just going to print out the current time in second with second after just date with time so nothing nothing is new at all except for a couple more print statements here we're going to let us know when we're making the request here we're going to see that we're going to sleep for three seconds before we come down here and say that we're calling run we make the run call so now if um if the timer starts here when the async weight is requested we would expect from this point five seconds to the time that we get the timer expire cold right if what's occurring is it's not until we call this um osteorun then it's going to be five seconds after this time makes sense okay so what we get is request for async wait for five seconds is that 13 seconds the sleep occurs we're going to call run three seconds later as we expected and at 18 the timer expired so that means the timer started at the request what we expected just like dad going and making the request to have a slushie made the slushie gets made right away right it's being made it gets put on the completion table but if you didn't supply the butler it's still there it's still done it's still made it's just sitting on the completion table waiting for somebody to deliver it and the person who's going to deliver it is is whatever thread called run you're doing good all right so we're going to just take a moment and we're going to go through bind um and if you read the what this talks about we're going to go through a couple different libraries yeah can you go back one good um one more or yeah that that one um so we still get to the done part right yes but but we're going to ignore that at the moment why were it done all right we're going to fix that so okay yeah you've used the library yeah okay um if you've used the library don't explain why we got it done yet okay we'll take care of that um so so last year um at boostcon one of the things that i learned was it was my first year the audience here is pretty large you have authors you have power users you've got people who have a couple libraries that they know really well and then you've got the rest of us mortals who just like move along and use what we can and we know certain libraries and we've never even heard of the rest right and the reason you know the library you know is because it solves something and then maybe it needed another library and so forth and so last year i personally was a little surprised the number of people that didn't know binding and so i thought we'd just go through buying in case there's some people here who don't know fine the idea is um here we're going to have a function vertical divide it's going to take two integers it's simply going to return the first argument divided by the second argument okay simple enough all right here is the bind call and the intent what we want to do is we want to bind something and create a functor a function object that later we can then invoke and have it call the thing that we bound to all right and we're gonna go through a couple of examples so that it'll all make sense and i won't have to try to describe it um so i'm going to bind to divide i'm going to use placeholders underscore one which would be the first argument when i make the call underscore two which will be the second argument when i make the call this here this bind has now created a functor as an object here i'm going to now take that object and i'm going to call that object the functor with two arguments 10 and 5. the result then of course is two um to be honest when i learned buying and i just kept i kept seeing this over and over in the documentation at first it confused me um so this doesn't confuse me when i first started we're going to use something that we'll just ignore at the moment a little bit but boost function it has a signature of it's going to return an integer whatever this function thing is it's going to take two ants and we're going to bind the functor to that and then we're going to use it so for me separating the two steps made more sense so here we're going to bind the exact same thing and now we're going to call it thumb 10 5 and then we're going to get 10 divided by 5 which is 2. all right we could swap the placeholders if we wanted it doesn't care so here we're calling it with ten and five but when we found it we bound the placeholders so that they're opposite and now even though we're calling it ten and five we're going to get five divided by two which we're doing integer division which is 0. thank you paid attention as well um we could also go ahead and not just buy placeholders we combine um actual values we can bind them in order we want we can have a whole bunch of things so here we're going to divide um with a 20 and whatever the fifth argument is and then when we call it we're going to call it with a whole bunch of stuff well we only care about the fifth argument so only the fifth argument is going to make it and so now we have 20 divided by the fifth argument we passed in six so that's two and we're gonna get ten all right moving on um going to use now an add and we're binding add with a 20 and an x so we can find a variable so when we call this we're going to end up with that is right here we're going to call it with no arguments why do we call it into arguments because we don't have any placeholders right so when it gets called here we're going to end up with 20 divided by what was x 5. um all right moving on here we have our x 5 20 just like before and now we assign x to 10 we call our func and we get 25. so the last time i looked that's not going to work 20 plus 10 is 30. so what happened well what happened was bine makes a copy so the copy of x at this point was five and so we're actually getting 20 plus five and not what we wanted how do we get what we want we use boost ref so now we're supplying it we're wrapping our variable inside of a reference and the end result now is what we wanted it's our 30. when this occurs it's going to use a reference to the x which is going to give us our 10. yes you go back to the last slide the last slide yeah this no uh the last last slide yeah right here i thought when you do a bind and you say underscore five that creates a function of five arguments no underscore five just means it's going to take the fifth argument at call time right but the buying function once it executes the functor that it creates of how many arguments is it it takes at least five but bonds will actually drop more on the floor it's a bind implementation decision well it's an implementation detail but it doesn't i thought that was just an implementation detail from a specification you weren't supposed to log no no why are you supposed to drop extras on the floor it's it's actually useful this is boost by the way yeah it's the one i know that that i believe stood by it works gr1 mine works the same way um can i point out that if anyone finds buying choosing if you have a compizer that sports land or vc-10 land's a super but it's a different one uh is that all also true when you use azio yes yeah like aci assume doesn't care what functors you give it so bind is just a convenient way to create functors so it'll accept built-in lambos as well cool okay um now we're going to bind to a member um inside of a class i'm just into a method instead of a class so we have this class adder adder is going to do nothing more than um inside of its functor take two integers um add them together i guess actually we don't use the function so never mind it's got add add takes two integers it's going to add the two numbers store that in last and return last um so here's what blind looks like it's the address of um of the method we want to call we have then the object and then we have our placeholders voila it works just like we wanted to except that we got back 24 but it thinks if i pull out last it thinks last is zero so i made a copy again if i use reference i get exactly what i want the other option is i could have actually passed an address yeah instead okay that was our wine tutorial moving on now we're going to use blind so um we're going to create two timers this time instead of one one's going to go up in five seconds one's going to go up into three when we do the weight we're going to bind the callback so we're going to bind the handler same handler but this time we've added an identifier a string identifier as the first argument and the the second one that we're still kind of ignoring at the moment so here when i use bind i'm going to give it the um the handler i'm getting it as the first argument timer one this one timer two and then underscore one the placeholder the first placeholder which happens to be um this error code so um where is your code going to be coming from then okay i'm gonna print out run and then we're gonna run it and voila it does exactly what we thought it should timer two which was only three seconds long went off first and we got turned on um all right let's do the same thing let's introduce a thread um we're not gonna talk a whole lot about threads but creating boost thread it's easy to create it from um here boost thread it's going to be called butler we've got one it's the object and then we're going to bind to that what it is that we want to have around in the thread so um the signature of whatever we're passing to the thread in the constructor um is basically a void void if you want to do something with it you better go ahead and bind or else you're not going to be able to pass something into it so what we're going to do is call in this case remember with our bind here's the osseo i o service run and we're going to pass it then by address the actual service itself down here butler join what this does is when the thread is done running when it's completed its execution this will then return so it's waiting for the threat to return we've added a sleep up here of three seconds and now let's see what happens all right timer one oh let's verify here five seconds and five seconds they're both going to go off at the same time all right both slushies will finish at the same time timer one we we enter it and then we leave it three seconds later three seconds later like we should um and then timer two as soon as this one was done it gets delivered and then it expires so i i kind of lied in the story with the butler went back right away well the butler hands the slurpee to the kid johnny has it mean about what johnny does with the with it um you know he might have to wait around for johnny to drink the slurky before he gets back to the show and that's basically what happened here he's having to wait three seconds before he can now go back and handle whatever else is on the completion queue okay let's use two threads because two is better than one everything else is the same we're now going to use this thing called a thread group and then we can take whatever the object is and call create thread we're going to bind our run again and now we're basically running twice this is like supplying two butlers to the slushy shack okay and now we're going to use on the pool join all so now what do we get well timer 1 went off 49 and timer 2 went off at i'm sorry timer 2 went off at 49 also they waited 3 seconds and then they completed so both of them are occurring at the same time that's what we expected both timers went off in 5 seconds all right post post is as if the owner of the slushy check got an order which he could service immediately he got the order and whatever it was just goes on the completion queue it just needs to be delivered he gets what has to be delivered okay so dad comes and says hey can you give this ball to johnny not a problem owner takes the ball puts it on the completion table as soon as there's a butler available the ball gets delivered to johnny how we do this is we take the i o service and we call post and then we just bind a functor to whatever we want to do so we're going to we we have a function up here which is going to simply print whatever it gets and so we're going to have do work is what we're binding and then eat drink and be merry we create a butler to run we run it and we get eat drink and be married so eat drink and be married got called by the butler pulling off the first one eat delivering it drink delivering it mary delivering it are you sure to get them in those orders if you you are sure to get them in the post order let me rephrase that hmm you're not guaranteed to get them in the post order unless you use what's called a strand and um we'll talk about strand in a moment or have one thread or have one thread but it's still not a guarantee or have one thread site library does not guarantee the order of delivery unless you use a string in practicality with the implementation you're going to get them in order yeah um all right um we're gonna do something a little bit different this time so we're getting excited now because now we know how to post things and we know how to create timers so we're gonna create a timer it's gonna go off in five seconds um timer expires just gonna print out the time time for expired we're going to um create our one butler one thread right here so it starts running and now in this loop we're going to go ahead and call post do work and we're going to give it the value so up here it's just going to say do work it's going to print out the time what work and whatever value number it's on right so one through or certain community zero through nine and then we're gonna sleep one second so post some work sleep one second post some work sleep one second so we we've got a couple requests sitting there right we've got a timer request that's gonna go up in five seconds and every second we're posting something all right this is what we get work zero through four timer expired done what's going on i mean it'd be nice if we got work zero through nine timer expired in the center because that's kind of what we thought was going to happen so um lie in the story number two all models are broken um but it can be easily fixed so this is how it works butler goes to the shack and he says hey assistant do you have a slushie for me and he says no but not only do i not have a slushie for you on the completion table the blenders aren't doing anything either why'd you just go home okay so if there's nothing in to be done if there's no work being done inside that's going to be pending for completion and there's nothing on the completion table the thread will end well that's pretty inconvenient if we want to just to stick there and keep working on stuff so what we do is we create something called work of work object so we're going to create this work object we're going to new it we're going to give it the service and then at the end we're going to delete the work object we're going to tell it we don't really we don't have any more work for you to do we're going to delete that object so let's take a look at what we have going on again same exact stuff here same exact exact stuff here um we're going to queue up and very little time all of the work to be done and then we're going to delete the work object but that's okay so um so let me let me back up and refer to that so so what happened before was the timer when the timer was sitting inside the queue waiting to be done five seconds the we were posting once a second something to something that was going to occur the timer completes let's say the post now completes we wait one second there's nothing to be done threads in make sense okay now what we've done is we've created this work object and that allows us until we get done cueing up all the work we want to be done to complete um it's going to hold on to that so that so that it's not it's not going to be finished so it looks like there's a blender doing something it's not really doing anything it's just a way of us telling it so now so now we're going to get them all because this is that work objective um so the work object can be on the stack but if you want to get rid of it at some point you can get rid of it there's all kinds of ways you can do this and i'm clear on the rationale for the uh for the behavior of um you know if you go back a couple of slides you got to you know the timer went off and things stopped right why does it behave that way um it behaves that way because um if you recall in our in that original diagram of the proactor requests are coming in and they're they're actually getting stuck in this request queue waiting for things to get done um there are things in the completion queue waiting to get passed out to wherever the handler was and if there's no work to to be completed then the whole service is not serving any purpose and so by default it just goes away well to me it seems like a producer consumer problem right at least that's how i'm thinking yeah right so you have a consumer who's waiting for something to be put in the queue right and it's going to wait and wait wait and wait until something gets put in the queue and then uh consume it right uh and that's not what's happening here exactly so so in order to do that you create a work object and so but when does this behavior useful i guess that's my question yeah okay good question um and actually i think we'll get to it here in a moment but let's just talk about it for for now and then we'll see it even again further let's say you have a client that's connecting to a server and what you've done is you've created an object that's going to deal with the connection to that server um when that when that connection goes away you want the client to go away too and it may be it may be that it's a temporary service that you're providing and you just want the whole thing to go away when it's all done it's it's a one-time service that you're providing or a one-time activity or a one-time set of asynchronous activities that you want to occur i have a thing where i have some serial communication going on and it needs to happen at the beginning of this certain activity of power up but after that i don't need it anymore and so actually that that's controlled by um one of these i don't give it a work i give it a work object until i give it all the work that i wanted to do and then i kill the work object and then i know that resource is just going to disappear because i don't need it anymore later in the lifetime of the project um so i i think you can make the argument that why right it's a producer consumer maybe it should just stay there all the time but you have the ability to keep it there all the time by creating a work object and if you don't need it then just get rid of it i think that's the boost waving it right during the review process somebody comes up with something that's just like whacky and say okay yeah okay i have this warp object i was just going to say that the run function will actually return once your queue is empty that's really what happens so there's a condition it's waiting on if it's empty it returns yeah because so it doesn't matter if you keep adding after the run returns actually if you call run again then it's just gonna finish off what's in the queue again right because in most cases there's also no way to insert any new work to do once there is nothing in the queue yes because unless you pass a reference to the other service somewhere else so your your work obviously it's a common way to detect example distributed state machines you've got machines that are communicating to each other as long as there's stuff inside of the message passing queue there's still work to be completed yeah but as soon as the queue is done and empty the state machines in essence have nothing else to do right unless there was a timer hanging out there's really nothing left for that machine to do the machine should just die so that's kind of a normal process with um i think state machines also but but not for producers um all right okay um here i've gotten rid of the of the um timer or the delay that we had up here so we're not going to wait anymore we're going to say we've entered now we're leaving we're going to have two timers they're both going to go off in five seconds we're going to have a pool that's going to have two threads so two threads waiting to hand out things they're both handing out because we found the completion to be time expired they're both going to hand their results to the tiger explorer so in three this is the slushies both got made slushies are both ready to be delivered johnny can't handle it right johnny can't handle it so we um we can eat we can actually see that we have both threads inside of the same um completion handler at the same time we're kind of getting stuff printed on top of each other um so if you're johnny this is going to make you sad right if you're susie you were smart enough you know how to handle both of them at the same time so what do we do about this other than locks we're going to create what's called a strand um and for some reason once a month somebody comes on irc and asks why it's called strain i don't know okay um but that's why that's why your example started on the image right yeah thank you yes consists of multiple strands that i tried that it didn't go anywhere on irc maybe because somewhere here but um well actually if you want to if you want to tie all your handlers into a single order you need a strand to do it we're going to do it whatever y strand is the name no no so you use the strand to tie them together so what this all looks the same as what we've had before this stuff right here right this is exactly the same we've seen all this here now what we've created is a strand and we've given it our i o service everything gets the i o service we've given our strand the i o service now what we've done is we're doing our bind as normal but we've wrapped it inside the strand wrapping inside of a strand guarantees that objects that are wrapped in the same strand will not execute the completion handlers at the same time it does not guarantee in order but it does guarantee that two won't occur at the same time there are guarantees about order um i point you to the strand documentation page and osceola a long description about a bunch of rules does it guarantee also that it is handled in the same thread no it does not guarantee that it's handled in the same thread so here we have two um threads running both are waiting at the completion cube right one is going to grab a result and take off with it it's quite possible that the other one is going to grab the other result but he can't actually deliver it until the first one returns that's all the strand tells you so they may be delivered by different threads but they um they're not going to deliver the same fact all right we do it now and timer one enters leaves and then timer two enters and leaves okay so we've gotten we've gotten what we wanted we've serialized at least um two two things so um had i went through and modified some of my slides at this point from now on to the discussion i keep saying use a strand okay it's like use a lock use a strand shared pointer quick introduction to shirt pointers if you don't know what they are so um what we're going to do with the shared pointer is we're going to take something that we've nude off we're going to give it to the share pointer it's going to wrap it and then we're going to use it like it's a pointer but when we make copies we're going to get some reference so we know how many are hanging on to this pointer and they're going to increment and then when they go away out of scope they're going to decrement and eventually go back to zero we're going to delete the thing we own right so we're going to do lifetime management so here entered scope just open your scope we're going to new off this new printer we're going to tell the my printer to print an 8 we're going to leave the scope and we're going to print that we left the scope and um we get entered scope printer created we print the 8 we're leaving the scope here the printer is destroyed and we've heard that we've left the scope okay i think um everybody probably knows shared pointers less people may know actually enabled shared from this um unless you already use um the insert design library and then you use it all the time so what we're doing here is we've created now a shared printer and we're inheriting from this thing called enable shared from this providing it the name of our class what this is going to do is and all this stuff looks the same we're going to have to add a method called get printer it's going to return one of these magic function things that has a signature avoid the end and what we're returning is we're going to bind to the print and instead of this which which we saw earlier when we were binding things or a pointer or an object we're going to use this shared from this and so it's not just this but we're going to have a shared pointer toward this that we're going to bind and then whatever that first argument is all right we have two scopes now entering first first scope we're just going to create our print we're going to create our function object vector we're going to then enter scope 2. here we're making our my printer with the share pointer we're going to call it like we're calling it before then we're going to go ahead and call this git printer and assign the result to print func so that's the thing right the shared from this so here at this fine point we now actually have a shared pointer here and we have a copy that has occurred through the bind and so we now have two references to count right let's count the two leafs go left go we're going to now use it print 42 leaving scope one let's go and so um what we get is interscope one is scrub two the sharp printer is created when we leave the scope it didn't get deleted which is what we wanted we then um used the func and then we have as we left scope one when that went out of scope the function object went out of scope then the shared pointer was destroyed okay this is going to help us keep the people on the beach that we want on the beach so i have a question pretending that i haven't used your pointer before um that's a really long presentation i've never used it pretty pretty dangerous um so i guess i get if i had to use your pointer before why i couldn't just say this there because then the thing that i stored the bound functor in the boost function wouldn't keep the printer alive yes but why do i need to use this here from this thing how come i can't just say construct shared pointer from this point okay so what's shared from the the short and i'll give you a short hopefully succinct answer what enable sharepoint this does is it actually creates a weak pointer um as a member um so at this point we are going to convert the weak pointer into a share pointer and return the shared pointer um so that what would happen if i didn't use that what would i yeah you got a new reference now yeah i have all right um all right so let's pull all this stuff together and see how it all works together because this is going to actually play directly into almost every pattern you're going to use with the asynchronous idle library um we're going to create a class of a typical kid like typical kids they cannot walk and chew gum at the same time but they can talk constantly right no it's going to have a reference to the i o service and notice down here we have our strand okay when we create it we're going to give it our i o service so that we can go ahead and hold on to that and use it later and we're going to for the strand we have to give it the i o service the hut that we're dealing with oh my goodness one of us is not working longer okay um all right let's look at walk walk is simply going to do nothing except for post that the the impul of actually doing the walk and it's going to wrap that inside of the strand because remember we cannot walk and chew gum at the same time so therefore we're going to post our requests to do walks and to do chewing of gum through the strand and we're going to bind a real implementation to do it so we have a public interface this is a pattern you'll probably use over and over again and as you get the request in how you're going to handle that if you can't do both things at the same time is you're going to post them and then post them with a strand and then you're going to get that executed by the butler right by your threads um talk we can talk anytime we want so we're just going to talk the walk info um it's going to do nothing except for start walking hang out for three seconds because he only walks three seconds at a time and he's going to print done walking chewing gum we get a flavor at least and it only takes two seconds to chew gum all right let's put this together so we have our i o service this time we're going to go ahead and create a work just using a share pointer because we're reinforcing ideas um we're going to create a butler pool inside of our butler pool we're going to have three butlers so we've got three threads pulling run created a scope and a typical kid of course it's johnny and um we're going to do one of these things off we're using a shared pointer for john we're going to go into this loop in which johnny's going to talk and he's going to walk and he's going to talk and he's going to chew gum and he's going to talk and then he's going to wait for three seconds not because of johnny but because i'm tired of hearing him talk so for three seconds he's going to wait and then we're going to do that in the loop of 10 times we're going to leave the beach which if you remember right if we left the beach and he wasn't in a shared pointer this would be bad the butler would try to deliver something to him he'd get exhausted and he'd die um as i leave the scope i'm going to call reset on the work share pointer which basically gets rid of it since it deserves and then we're going to join all the partners all right so um we got created he starts talking immediately and you can see start and end walking which have the pluses and chewing gum which have the minuses they never occur and relieve with each other which is exactly what we wanted talking seems to occur all over the place but the walking and the chewing is dumb they never occur at the same time make sense perfect all right we're moving along well oh perfect all right we only need a couple more things that that um kind of just like either the ir is right there i'm sorry thank you we're gonna talk a little bit about a few things you need to know about um oscar first to be able to move forward and then do some communication um as i said earlier this library is very extensive there's a lot of stuff in it and it's one of those things that if you're like me you'll just have the reference page open as you're using the library and and referring to that a lot but there are a few things you should know it has a concept of this thing called mutable and const buffers think of them as a pair with a pointer or a const pointer and the size of the thing everything's going to deal with memory buffers right memory buffers we just described as a pointer and some length um in reality oh an immutable buffer can become obviously a const buffer not the other way around you cannot make a concept buffer obviously into immutable um in reality these things are classics and they're just going to wrap the memory the cup that you own it also supports scatter gather gather if you don't know what that is then you don't have to worry about it if you know what it is then you're probably already concerned about it um if you had a vector or some container standard container of these mutable buffers or const buffers they will perform the scatter gather for you so he knows how to do that it understands containers of buffers buffers do not own the underlying data you have the underlying data you're just wrapping it with the buffer make sense that's really important if i see any of your handles on irc asking about that all right it's really really really easy to get an oscar buffer okay there is a free function um called boost osteobuffer that has like 27 overloads or something like that it will create just about anything into a buffer for you you'll just get the right one all right and you'll go to that reference page and you'll make sure that you get the right one if not it'll tell you what to do to get the right one right that's how you do it here are just some simple examples of us here using a socket we're going to send something we're wrapping our data and some size with a buffer here i have a string it already knows how to take a string and create a buffer directly out of it here i have a boost array it knows how to take a boost array and wrap that into the right type of buffer right it knows a lot of stuff already how to do it um standard like vectors and things of that sort of pod types um just go look there's lots of stuff one more thing we need to talk about just briefly is the api there are free functions such as the async read async read until until you see something async bright async read is going to read however much we told it to read it's going to write however much we told it to write these are at the shack level the top level it's going to make sure all the operations underlying that that needed to get done for that complete because if you've done network programming you know that if you tell it to read a thousand bytes you likely don't have a thousand bytes you're going to get them back in chunks it's going to take care of that for you there are also based on on the objects there are methods for example async reads some it's my favorite it's going to give you back what happens to be available at that time which is likely not how much you need but depending on what kind of operation you're doing you just start working on whatever you have at that moment and there's a writing song all right let's get going we're going to now create our flash xml server the reason we're creating a flash small service because when this this topic or when when the the call for papers or whatever went out literally in like a two-week period there were five people who said how do i make flash talk with ossio so i thought maybe it must be popular and i personally do it all the time so um but it's dead now so i don't know what i'm going to do so we have this it's a we're just gonna make a typed up to make our life easier here um this is how i personally want to use it you might want to use it a different way i'm going to have a type of this osteogeneric server serving is something we do a lot of and serving typically exists of the exact same thing which is you're going to listen on a port and when somebody connects you're going to pass that off to some handler to take care of that client connection and then you're going to wait for the next person to come and connect to your port and then you're going to do the same thing so um after a while you're tired of writing that over and over again and you just abstract it out and so i abstracted it out and i just call it this oscillogeneric server it's going to take the type of whatever that handler is the client handler and um and here i'm telling it i want one thread but you can have whatever you want so in your generic survey assuming this is tcp for my server okay all right yep because um just making sure that's what i do a lot it's this this code's also been munched around and made a little smaller hopefully for us together i'm going to start the server and i'm going to give it the port i wanted to listen to i'm going to add a connection handler for as clients connect i wanted to be able to call something back which is going to be this xml client connection is going to get the handler that has just been connected when that occurs it's going to take the handler and it's going to add another handler a message handler so as it gets messages in because i should have said this so flash the most convenient way to talk flash to something else is xml but it's just the easiest way to do it and so when you send messages um you you send these xml things and they happen to be null terminated and so you're going to get xml messages out that you're returning it and that's and that's what i want to process i want my servers to be able to collect these and use them um and so i'm going to add a to that handler that's just connected i'm going to tell it this is what i want you to deliver the messages to whenever and so i'm going to do something cool inside there i don't know what it is yet this thing here for this omdxml it's not really accidental and um for now just assume it's like an xml node thing it does something all right let's look at it so the server class this is what's going to handle our incoming connections um this one happens to use signal we'll talk about that later um and so how many people use signal okay just think about it as a way to collect a bunch of handlers that want to be called back later i can make one call to this functor and all of them get called back so um probably shipped great it's not public yes um um it's going to have some things that are mostly not interesting it's going to take a thread count this thing's interesting we're going to start the server we're not going to worry about how we're going to stop servers at the moment we don't have time for that um what's contained inside here is this thread group because you know we're going to have however many people we want to to work on our beaches or however we want um notice now this is a little different i'm making some assumptions here i'm not going to take in an i o service i'm going to create the i o service so for each server that has a port it's just going to have its own i o service there's one slushy cut for each port that you're listening on that's that's my design that's what i wanted to do um and then we have this thing called an acceptor and we'll we'll get to that all right start server all right so start server took the port in what is it going to do um we'll get to this let's get to this right now it's first going to um new off whatever the handler type was that we wanted so this is the guy that this is going to handle all the communication and we're just going to new one of these off um and hold on to that as a handler so as a connection comes in the server's job is just to pass the connection off to the handler and it's going to take care of client communication it and you'll see this pattern over and over again if you look at the examples too connection comes in we just create an object to handle it it handles that connection and now we're going to set up actually the list app um we're going to create an endpoint and we're going to tell the endpoint what type it is and which port it's going to to be associated with an acceptor does exactly what you probably think it should it's going to accept connections um we need to tell it what type of protocol to open with this is the protocol the endpoint or in this case the v4 um you can set options on it i'm going to set the option of reuse address if you don't know what that is don't worry about it it's just standard sockets i'm going to bind the acceptor to the endpoint itself so i'm going to say acceptor you're bound to this endpoint which is the port at some protocol and oh yeah start listening okay this is similar to um what we had before with the timer and we told the timer to do asynchronously start same type of thing um and then we're going to start accepts so now we're going to basically start this accept when a connection comes in accept the connection handler is going to expose its socket the one that we created up here it's going to expose its socket so we're going to give it the socket and we're going to bind the connection um we're going to bind the handler so here's the handler being bound handler it's going to be passed as so so it's a a method of this as this one um the handler is going to be passed as an argument we're going to copy this right by value which it's a shared pointer we like that um and then this is like the underscore one that we saw earlier but they're really nice inside the library and they created a whole bunch of placeholders that represent all the different things that are in the library and so instead of using and trying to figure out is this the under score one or the square three just you can just use these error and then we're going to create however many threads that we wanted that are going to service then the i o service how we're going to be are we okay with this handle new connection so remember this is what gets called when a client connects so once the client connects then handler handle new connection is going to get called we're going to get the handler some error code if there's no error then i'm going to whatever this start does on the handle i'm going to tell the handler hey start start doing whatever you're going to do this is the magic with signals we're just going to let the rest of the world know that um that we have a handler that disconnected we're going to create a new handler this is like bringing a new cup we're going to create a new handler to handle whatever the next next client client is that comes in and we're going to bind again ourself this time right so we're binding back and so this is going to just stay basically um it's like johnny making the request back the handler is making the request back all right let's yeah just because because i want i want to now get the next connection so if i didn't have this nothing else there's no more connections that i can accept and they originally somehow register this comeback in a way that it will automatically so it's like saying my timer got done start the timer again my timer is done in the handle start my timer again um i got my new connection i i do the things that i need with my new connection and i create a another thing to take another another object to take the next connection and i bind that in and say okay except the next one oh if it turns void you could have returned boolean and somehow this is not going to get returned anywhere this is the butler getting calling this right the function turns either there is a function it turns away yes yeah the earth could have returned boolean and the framework would have depends on what uh could have decided oh the black ones registered itself again no no so the reason it can't is because this is the handler that got called when we got a connection so we told it here's the asynchronous thing i want you to do accept the connection and when you get one that's handle or no the handler is now being told i have an exception and connection connection so now that what's that handler supposed to do i mean the best you can do is tell the calling thread a return type the calling thread doesn't care right it's completely asynchronous so if you want something else to get done you need to you need to do it now you have to you have to actually set up another asynchronous call yeah here and so one way of thinking about this is you're going to be chaining these asynchronous calls together to get work if most of the done this is what they are going to do why the claim will be not doing this i mean if this is what everybody's going to do so you get to handle your connection you pass it up handler and then you register again i think why is not doing it where what is it going where's it gonna go back to do the same what's in guy this you don't know it doesn't know here it can't go to here and then you can do a problem why don't you just tell you where you you tell it where you want it to go back to which is what we just did we told it we told it we want you to accept another you have to make an asynchronous request right there isn't one yet so we're telling you here's an asynchronous request there's a difference here oh is this what you're asking about this one no the difference between this statement the one that was originally yeah this is it's the same this is a different object it's a different client because okay so this handler is going to handle one client that's it i got to create another handler to handle another client and another handler clip because because i'm going to work that's how i'm going to worry about it at least we've got this to get rid of the code location right between that and the shirt yes yes you definitely could do that yeah what you could have done in this case is create a new function say create and start accept exactly and then it's one function and then you call it there and we'll see that in the handle actually yes so the answer to the question why not return bull is because uh in your in in i o service run what actually happens is it just pops off a handler in the pew and calls it that's all well it could have done something else something else no but but you're assuming but it couldn't do anything else so what's happening so think about this framework i mean it's used for everything from um you can register did a directory change with a file handler you can register serial port io you can register and all kinds of different things right for asynchronous things if you look inside the api and there's there's hundreds of asynchronous um entry points that we can do well what's the default supposed to be for anything and remember you're going to if you you can actually also post a math calculation so would you make it return true or false so you're using using a single queue to run all your handlers so that's that's the real reason all right this is um our itty-bitty handler this is the thing that's going to take care of the client communication it's got some fluff this is the signal thing that's going to pull back when we get a message um we're going to be able to create one give it to service there's a start that we already saw it's going to start this thing going whatever it does there's some ways to do sending before i send this whatever the sectional thing is or we can send it as a string but that's a definition and then we can access some different things let's take a look all right so we have these private members this time we want to know the i o service but we want to know we want to know the eio service right so we're just going to have a reference to the io service um we we've created the socket we know the socket or the client so we're going to have the socket we actually gave that to the server if you remember before to do the listen um a strand because there are going to be some things that i don't want to happen at the same time it's going to make my life easier you can optimize later if you want so in the constructor i need to take care of the things that were references um some more fluff this is the getting the message handler in and the socket return okay back in the generic server we made this start call this is all start does it calls read packet all read packet does is it creates it starts this asynchronous read until remember that yeah your laptops and your phones so this is a free function we give it the socket this is like the free function of going to the owner of the shack and giving him the request and the thing and all of it to get it right so it's free um we're giving it the socket we're giving it here the in packet where we're going to read things into it's a read until i'm telling it just to read until you hit a null i don't care how you do it i just read until you get to that point and then when you're done doing that this is what i want you to call uh repack it done gears are shared from this um here then i want to know the error and i want to know with the placeholder how many bytes were transferred i want to point out at this moment now this shared from this is being bound it's being stuck on the async queue of things to get done that means that i have at least a reference count of one to myself so if everybody else in the world gets rid of me i don't care right just build one any sense okay you're not gonna leave the beach because you have a slushie being made um one word costume here because this comes up a lot async read until um if you know something about how this data is coming in it's coming in in chunks okay you can create a regular expression here and read up to some regular expression or some other thing it's reading it's looking at the chunk of of memory that it has and it's looking at that and says i got what i wanted it might have more stuff after that there might be more inside the buffer after the null but i met the condition which was read until i got the null so don't assume that what's inside the buffer is just up to the null because it likely isn't depending upon what your protocol looks like you probably have another beginning of a message after that point and um so if you just throw everything away um let's back up and i can show you that's this is what in packet is because i didn't actually say that it is this thing called a stream buck it's perfect for this type of application so it is just another type of buffer that that osseo provides when you don't know how much you're reading in and later i'm going to take out of the stream up to that point and then the rest of the stuff's still in the stream and then i can continue to read following that right so i'm not going to lose it is it just the character or can you give it to me it could be a regular expression yes it could be very complex there are overloads there's a bunch of overloads yeah so to take a look at the um and and it could if you use my utility it can actually be a a key grammar yeah so um we don't have time today i was hoping that we'd be able to get to it so for those of you who are in the spirit discussion yesterday we talked about the protocol um example so you saw the grammar and you saw a rule and what i actually have is a utility which i supply a grammar and a rule and i supply a socket or a well anything that basically can have an asynchronous thing done to it so a serial port and whatever and you just get back your ast and so how this actually really works for me in real life is the handler gets back the ast which simply then calls just passes the ast to the other side and the handler and so i don't think about it at all it just brings in serial and it outputs xml um and i hope to give it to you guys someday all right read packet done this is this so remember we set this up read until um and what we're going to read until we hit the null and when you get that call this repacket done what if i want to process the data in chunks myself you you would do what i normally do which is read some async read some and then you just get what happens to be available at that point because you just get chunked back all right read back it done if error do something clever all right um clever might actually mean just return if we return you die the handler is done the shared pointer will end up having no more reference the client will get destroyed hopefully you're smart enough in your destructor to shut down and then close your socket that's the proper ordering to do that in and it just all goes away right you don't have to think about it what happens if i throw an exception inside the handler um there's no way to catch it all right yeah you would get it at that point so i catch them anything that's going to throw at cats inside my handlers and i deal with it in some way um and if it's dealing with it by simply returning so that i just destroy myself that's fine with me um all right so um here's some of that magic that we won't talk too much about but we're going to create this something called an xml node um and then we're going to tell it to parse in the data that we got and now i have an xml thingy and i can ask it's node name and if it's policy file request um how many people dealt with flash before none of you even care then it has a whole security model and you have to tell it back i don't know anymore anyway yeah anyways so uh it's requesting some policy and whether or not client this client's allowed to connect to you or not and if it does then you just reply back and i'm just telling everybody okay anyhow otherwise if it's not one of those then i'm going to update my hand alert by passing it a shared from this a pointer to me so i don't go away and the packet that came in at the end i'm going to call three packet so that's the factorization that we talked about in the other slide this is going to start reading another packet cindy all right i've got um two ways to sin i need to pass it this thing which just becomes a string eventually or um it's called here or can send a string the string notice what i'm doing is i'm calling post and i'm wrapping it inside of my right strand there are some things that i'm doing internally i'm going to have a cue a queue of things that i want to write to send out and i really don't want to deal with the fact that a whole bunch of people can be calling me different threads could be calling me to send stuff out so what i'm going to do about that i'm just going to wrap it tie it with a strand so here's the strand it gets wrapped and it's q messages q message simply looks like this um we start off by checking to see whether the queue is empty or not that tells us whether there's a write in progress we'll see that in a moment um we push back the message onto the cue if there is not a right currently in progress we start the sentence this normally if you looked at it you would just you go oh my goodness this is going to crash instantly but it's in a strand right so this is perfectly safe i am guaranteed that cue message is only going to be entered by one thread at a time they're going to be serialized for me so going back to the use locks use strands they're your friends it makes all this really hard stuff easy because otherwise you're going to have to figure out the hard part of getting things on and off the queues what happens if i uh register for the same event twice read some free time um well you could do that it would be like ordering two slushies so you you would read some and then when when that one's done you've already got another read sum okay right now if you had multiple threads you might actually end up having some problems here yeah yeah same with rights yeah uh i mean this seems to be a common problem too people people want to actually just start blasting writes to a socket you would never blast writes from multiple threads to the same socket in a normal sense don't do it in osseo either because you're gonna get exactly what you asked for right you've got a single pipe and you're going to be shoving data from a whole bunch of different places down to one pipe and this is going to become a little mess but couldn't it be that that's more efficient to have more than one reeds because your read handler consumes some time and say you have a udp connection that you're reading from start another right away yeah remember as soon as we call the async that thing starts yeah sure but uh when in your handler uh you you do some work a little but still if you had another read going on that could dispatch okay but um so coming into your handler the very first thing you did was issue an async read that it doesn't it doesn't start when the handler finishes also yes you can do what you're what you're saying but instead of doing the read at the end of your handler you schedule the asynchronous read yeah so we could this could have been up here up here and it would have started well next read immediately yeah or actually after after that we could have then started the next read right away um but the other thing to keep in mind is your back your stream it's tcpip the layers at the bottom are already bringing in the data for you they're coming in right the reed really is pulling the stuff out by chunks whatever happens to be available reassembling it and we're not we don't care about chunks we're reading until a certain thing occurs so i don't know in this case you wouldn't get any improvement okay so i have a really stupid question probably not i'll plug it really hard and then i'll reveal my ignorance of all things and tcpid but can you advance to the next slide uh there so so you're you're cueing packets that you want to send and you're maintaining your own cue this is exactly this what asio does that it maintains a cue for you and and will send the packets off um so this is the problem if we start on on a socket just i have a socket and we start sending information on that socket and then another thread comes in and starts sending information on the same socket they're not going to get cute i'll walk in front of them we're both going to actually be riding to the same socket at the same time and we're going to end up with all the data mobile together and so in order to start at least five minutes serializer okay um we need to cue it and when one's done we need to then well then wouldn't a right string handle that yeah well that's what i have here but then why did you guys hear it what's the queue for michael what you could do you could wrap up the message itself with the right hand oh yes yes no you could have done that and you didn't need that exactly i'm sorry good point yes okay that no that's true um yeah and it would change my hand a little bit um and we'll talk at the end maybe how that would change so something's gonna happen here in a second and then we won't have to do that again good question um xml node is that a reference up there and safely in the screen this is being received by construction uh the one on top uh the node is that a reference and also down messaging they're both they're both being passed by felony okay so as eric points out there possibly is an optimization here do we understand what we're doing here though because it will be important for the next one so the string is possible we won't worry about that it got only it there's no copies at all you have to read the website all right start packet send it's going to pop the thing off it's not gonna pop it's gonna take the thing on the front the string on the front it's going to add in our terminator and it's going to call this async right giving it the socket and then here's the free function buffer and we're going to give it basically the string it's going to create the buffer for us notice we didn't pop it off the queue that means it still exists so the eric method we got to figure out how to keep our memory existing because if it goes out of scope remember this doesn't own it it just wraps it so if we have another way to keep it alive which we probably shared pointer yeah i think it can wrap a shirt pointing and i don't know i don't think that's true i don't think that's true i have to think about that but as soon as the right handler took the string and um and called async right and did this if that string then went out of scope which it will i'm keeping sure from this but if if the string that i was trying to write was bound to the handler it's not in the shared this scope right it's going to go away but you can wrap the buffer in a sharepointer and supply that to packet said and done but the buffer in a shared pointer doesn't help me because the buffer doesn't own the data yeah how about uh your own buffer for me that was the easy solution um oh and then the handle here is packet send done all right packet sent done if there was not an error at this point now we've popped the thing off the front we don't need it anymore the way it goes marshall into the tape that's almost in so when i received them i pushed them on to the back of the queue when i processed them i use them the one that's on the front of the cube when it's done when it's done it gets popped off the front of the cube there's only one way there's no way they're going to get out of it it just won't happen unless you believe in all that stuff from the talk yesterday then i don't know what's going to happen something else um and then if there's some air on the sand we could do something clever down here oh and so i'm here so we're going to pop it from the front and remember we're the only person looking at this cube because it's in a strand um we're going to check and see if it's empty if it's not empty we've got something else to do and we can start the end again yep by starting the sin we're going to start another asynchronous thing happening which is going to get us shared from this bound to some handler and we're going to continue to stay alive as long as we have asynchronous stuff and handlers but as soon as we run out of those we're done we're gone which is exactly what we want right we only want our client object to stick around as long as things are great and we're working with the asynchronous io um okay did all that make sense all right this is this is the um a couple words here um we were just in in this example what we were doing is we were just calling some handler that did some stuff from our pre our earliest examples when we had the timer going we know that if we call a handler and it's taking a really long time to do something nobody else is getting their slushies served right that could be a problem depending upon your application if that's true in your handler a really simple way to take care of this is you can have another i o service and you just post work to get done so it does nothing more than takes the call back it binds some work right the actual function that you want to have process the data and it sticks it on so now we have two i o services we have an i o services that's handling rio and we basically have um a thread pool that's doing our calculations or whatever it happens to be that's like a real simple way to handle this problem of um blocking when you have io occurring in some long operation all right okay um next word of advice um i use signals really what you want to do is use signals too so if you if you have a situation that's very similar to this where you have handlers that want to know information that's occurring um signals is the way to go and signals 2 is the really the way to go because it handles um all the threading headaches that occurs with connections and disconnections when it says that signals 2 is thread safe that's what they're talking about they're not talking about all the stuff that you might hope they're talking about the connection handling of connecting in a handler and removing that handler or what if the handler goes away and you didn't know about it or what happens when somebody comes in and another one tries to connect at the same time all those problems you have to deal with with multiple things connecting or disconnecting it takes care of so signals 2 is the way to go um the final thing new strands strands will help you in all kinds of situations when you when you're starting to write these things you start to look at it and it's becoming complicated and you start having locks and you start having all kinds of other weird things going on and the problem looks hard just step back and say all right that must mean that i have things that can't be happening at the same time let's use a strand or multiple strands to make sure that those things will not happen at the same time all right that's it um okay yeah actually that's a good question um so the presentation will be up i'll send it to her it's my fault um and yesterday's also will be up and as i mentioned yesterday the code um for all of yesterday's spirit stuff all the code that's in for for this is all set up in little compilable test programs with a jam file and how i recommend is you just take the the tar bowl unzip it inside of the boost 143 it'll create something called boost con go inside there just take some d jam and then everything will just work okay and then um then you'll have all these examples to play with you whatever you want all right