Nonblacking I/O on the planet Asynchronia256/16

A short story loosely based on uncertain facts.

Supermassive black hole at the center of a galaxy surrounded by an accretion disk - NASA/JPL-Caltech

“Grandpa, what’s a nonblacking I/O?”

“Why are you asking?”

“You have it on your t-shirt: Nonblacking I/O for the win.”

“Oh, right, I do.”

“So, what is it?”

“Do you know what’s blacking I/O, because this is just the — ”

“No.”

“Great. Do you know what is I/O at all?”

“No.”

“I/O stands for Interpersonal/Operations.”

“Why the slash, then? Wouldn’t it make more sense to — ”

“Listen, kid. Do you want to know what’s nonblacking I/O or not? I don’t have all day.”

“But mom said that we have all day and she’ll take us back from the lake tomorrow so we — ”

“I/O stands for Interpersonal/Operations. I’ve been working in I/O all my life. But it wasn’t all roses and daisies like it is today. We used to risk our lives, kid.”

“Lives? What’s so dangerous about sitting all day and handling papers? Getting paper cuts?”

“You know that we don’t have silicon on Asynchronia256/16, right?”

“Why is our planet called Asynchronia256/16, anyway?”

“Because it’s a 16th planet in the Asynchronia256 system, obviously.”

“Yes, but it’s the only inhabited planet, wouldn’t it make more sense to give it a shorter name, like The Planet, or Ground?”

“It’s the only inhabited planet for now but it doesn’t mean that — ”

“And what’s the deal with Asynchronia256, it’s not like we have any other star nearby.”

“We started naming the stars in the the Asynchronia quadrant starting from Asynchronia1. Ours is the number 256.”

“This is stupid.”

“So how would you call it, smart ass?”

“I don’t know, The Star? We could say starrise and starset instead of — ”

“What’s wrong with asynchronia256set?”

“I don’t know, it just doesn’t feel — ”

“Listen, kid. I don’t have — I don’t want to waste all day. The point is that we don’t have silicon on — on our planet.”

“What’s silicon?”

“It’s a hypothetical element that some say should exist. We discovered elements with all atomic numbers between 1 and 137 — ”

“Why not 138?”

“138? Don’t be ridiculous!”

“Why it’s ridiculous?”

“Listen, kid! Do you want to tell me the story or not?”

“Yes, grandpa.”

“Fine. So we discovered elements with all atomic numbers between 1 and 137— except 14.”

“Even 119?”

“Yes, even 119. Why 119?”

“It’s a nice number.”

“Fine. Even 119. But not 14.”

“How does element 119 look like?”

“It doesn’t matter! We’re talking about number 14, the silicon.”

“Why is it called silicon, grandpa?”

“It’s called after a con that took place many years before you were born. So many people invested all their life savings into those mines where supposedly the element 14 was found that our economy almost collapsed. It was called a silly con because of the silly claims of the con artists that started this all insanity. The strangest claim that they — ”

“Grandpa, but what’s the big deal with element 14, anyway?”

“Don’t interrupt me. I was just going to — Where was I?”

“You said that we found element 14 in the mines — ”

“No, I said we didn’t find element 14. It was a big con and a pretty silly one at that. That’s why we call that element silicon now. Haven’t you heard about the Silicon Alley, where all the comedy theaters are located?”

“No.”

“Never mind. The point is that we don’t have any silicon on Asynchronia256/16 and we can’t build even a single transistor.”

“What’s a transistor?”

“I don’t know, it’s just a made up name of a hypothetical device that could allow processing of information without the involvement of people.”

“Sounds crazy.”

“It is crazy. Those crackpots say that if we could find that element then we could easily build machines that could use logic, could you believe it?”

“Well, actually — ”

“But we don’t have this magical element and we don’t have any machines that could process information and perform calculations.”

“I know we don’t, why are you telling me that?”

“Because I want you to fully understand what I am going to tell you in the context of not having any non-human computing power on the entire planet!”

“I know we don’t have any non-human computing power, grandpa.”

“Fine. Can I continue now?”

“Yes, grandpa.”

“Will you be quiet now?”

“Well, if I — ”

“So that is why working in I/O is so important. This is the only way to process information, and we have more information to process now than ever.”

“And what were you doing, grandpa?”

“I was the server. I served information to people who were asking for it. It was a very responsible work because I was exposed to the public and protected only by the interface.”

“What’s an interface?”

“When a server talks to the client, the interface is the bulletproof window between our faces. Before well-defined interfaces were developed and standardized it was a mess. A real mess. But with a standard interface I could always change jobs any time — ”

“But you never changed jobs, grandpa.”

“It doesn’t matter! The point is that I could if I wanted to. As long as the client respects the protocol, I could serve any request. And man, I was good. I was the only server in my data center who’s never used my 500 card, not even a single time.”

“What card?”

“The 500 card. We kept numbered cards with response codes that we showed to the clients to make it all faster. So we had a 200 card that meant OK, a 404 card if the information that the client asked for couldn’t be found, 301 if it was moved permanently to a different data center or a different server. I liked the 204 code because it meant that everything is OK but I din’t have to return any data to the client so all I needed was to quickly flash the card and I was done with the client. But the best one of all was the little known — ”

“Grandpa, but what’s the 500?”

“The 500 was the ultimate failure. It meant that everything was OK, the client, the protocol, interface, the query, and yet you failed as a server. The cards were all in the special drawers: a 1xx, 2xx, 3xx drawer and so on. Opening the 5xx drawer started an alarm and you were required to stop serving requests and wait for the administrator. It was the biggest shame for a server.”

“OK, grandpa, but what does it have to do with nonblacking I/O?”

“Everything, kid! I remember how it all started when I got hired as a server in the first data center in town. I didn’t even know what is it all about, no one did. They gave me a simple interface and told me what to do. Even the protocol was much simpler back then. We didn’t even have response codes! Can you believe it?”

“So how people knew there was an error?”

“They didn’t! I mean, I gave them a response as a piece of paper with a text like: ‘Sorry, we don’t have such a document here’ but some people actually thought that we found the document and it had a content like this. So we had to introduce the response codes in 1.0 to make it all clear.”

“Really? Didn’t they read what you gave them?”

“Some of them didn’t. Some of them put them in their own files without looking. Some of them were just proxies.”

“Who’s a proxy?”

“Proxy is someone who acts as a server in some other place but instead of having all the information, he just goes to other server and asks the same question that he was asked by his client.”

“So is he a client or a server?”

“Both. For his client he was just a server. And for me he was just a client. The only difference was that they sometimes showed you the XFF papers.”

“What’s XFF?”

“It’s a power of attorney printed on the X-Forwarded-For form. But we often ignored it because we couldn’t usually trust them. Unless those were our internal proxies who were working for us.”

“Did you have a lot of those proxies?”

“None at first. We didn’t need them. I was the only server in my department and still I served maybe a few requests per hour. No one was using that system. You kids today know where to go with a joke on a piece of paper so that all of your friends could get it and laugh. But people didn’t even know what to use our data center for back then. They didn’t even know the protocol. They saw few 400 cards and gave up. But the life was simple.”

“Simple? What’s so complicated now? I go to the server, give him a request and get a response. Easy.”

“For you it’s easy! But you don’t even know what’s actually happening. You only see the front end. When a server has to stand up and go to the back end of the data center before he returns with a response for you, there is where all the complicated work takes place. But it didn’t always work that way.”

“I’ve never seen a server standing up. I just give him my request, go home and wait for the callback. Then I come back when the response is ready.”

“But it didn’t always work that way.”

“What do you mean? You told me that you got requests even where you started working.”

“Yes, we got requests, but we didn’t use callbacks.”

“So how could I know when to go back to the data center for my response?”

“You didn’t. You had to wait.”

“What?”

“You had to wait until you got a response.”

“But it can take hours. What was I supposed to do during that time?”

“Nothing. You just had to wait because if you went home before the server came back with a response, he didn’t see you and just dropped the packets on the floor, so the garbage collector could collect it later.”

“Did I even know how long it would take?”

“Usually for simple requests you could make some estimates if there was not a lot of traffic, but the server could be back any minute or could be stuck forever for all you knew.”

“Why would anyone even use such a system?”

“Oh, it wasn’t that bad in the beginning. As I said when I started I was the only server in my department and I served few clients every hour at most. So I was the one who was waiting most of the time. When someone gave me a request I couldn’t wait to serve it, I was so bored. And those requests were simple. People didn’t know what to ask for. They came to me because they were excited to see the new system so they asked me about the hours when some restaurant is open, or how a new car looks like. I got it all in the drawers at my desk so I didn’t even need to stand up to serve the requests.”

“Did you have information about every restaurant in your drawers?”

“No, only those who paid us for hosting. Very few restaurants did it back then and it was all so new that their clients came to me even if they already knew the opening hours, just to see the new way of getting that information. They didn’t even know what they need and when I handled them some ads they read it with interest!”

“Ads? No way! Didn’t they use ad blockers?”

“There were no people who were specialized in working as ad blockers back then, because there was so little information in my drawers that people were interested in everything, even the ads.”

“Hard to imagine.”

“It is now, when you get every response wrapped in a pile of ads but the times were very different back then. We were just starting the revolution and we didn’t even realize how popular it would get.”

“Grandpa, but wouldn’t a single person like you have a terrible scalability characteristics?”

“Of course. And we were about to learn it the hard way. It all started during the Olympics. We were hosting the official Olympics website and I’ve seen some growing traffic few weeks before the Olympics started — people asked who is competing with whom, at what time etc. But when the Olympics finally started, it was beyond our imagination. Hundreds of people waiting in lines. They just wasn’t able to understand why couldn’t we serve them on time.”

“What they were asking for?”

“During the marathon they were constantly asking who is first. Or who won a race after it ended. I had to give the same response to all of them over and over again because a lot of them were asking about the same information. I cached the most popular responses on sticky notes but it wasn’t enough.”

“Couldn’t they wait until the lines get shorter?”

“No when they were betting on the Olympics results. They couldn’t wait. People in lines started to organize and swap information among themselves in a peer-to-peer fashion but the information was not reliable and not up to date. Soon it was such an angry mob that we had to close our data center for the first time.”

“I have never seen a closed data center.”

“You have no idea how many complicated mechanisms are at work so that today’s data centers can handle so much traffic. But we didn’t have any choice back then. We had to close and reorganize.”

“How?”

“The most obvious way was to open more windows with more servers. When people entered the building they were greeted by your uncle who just started working at that time.”

“You mean uncle Robin?”

“Yes, uncle Robin. He greeted every person and directed him or her to a different line, so that every server could get a more or less similar traffic. We called him Round Robin because he wore a big round hat. Boy, he looked funny in that hat. But he had to be visible in the crowd.”

“Did it solve the problem?”

“Yes, for some time. The lines eventually got as long as they were before. Only there were more of them.”

“Couldn’t you open more lines?”

“We could. And we did. But every process, as we called those people who worked as a group serving the same kinds of requests, required a lot of space. Soon it started to cost too much.”

“So what did you do?”

“Actually your grandma saved the day by giving me a great idea.”

“Grandma?”

“Yes. One day when I was resting after work I looked at your grandma who were cooking dinner, watering flowers, washing dishes and stitching— all at the same time. I told to her: ‘Maybe you should work at our data center if you can do so many things at once.’ And she said to me: ‘But I never do even two things at once,’ she said to me. ‘I only do one task at a given time, I just switch between them when I can and eventually everything is done.’ She said that her great grandmother called it multitasking. It didn’t take long until this archaic word entered the jargon of our data center forever.”

“What grandma knows about data centers?”

“Everything, as it turned out. More than we all did. I realized it some time later when she showed me four pillows embroidered with flowers and told me: ‘Look what I finished today.’ to which I asked: ‘Which one?’ and she said: ‘All of them.’ I asked: ‘Did you do them all today?’ She said: ‘No, it took me four weeks.’ I asked: ‘So one week each? That’s a lot of work.’ to which she answered: ‘Yes, I guess it would be one week each, if I did them in series.’ I didn’t know why it bothered me at that time but I’m glad it did. I said that surely she wasn’t embroidering four pillows at once because she didn’t have four hands.”

“And what did grandma say?”

“She said that it’s enough to have four needles. And four threads.”

“Makes sense. And what did you say, grandpa?”

“Nothing! I didn’t get it yet.”

“You didn’t get what, grandpa?”

“You’ll see in a moment. Some time later she showed me not four pillows but four cakes and said, just as she did before: ‘Look what I just finished. It took four hours but it was worth it.’ to which I asked automatically: ‘So, that’s an hour each? A lot of work.’ And you know what she said?”

“What?”

“She said: ‘No, there’s no way I could make one in one hour. Not even in 3 hours.’ First I thought I didn’t hear her right but then she continued: ‘It has to be baked for two hours and then cool down for half an hour before it can be decorated and put into the refrigerator for an hour. That’s not even counting the preparation of the ingredients.’ So I said: ‘Wait a minute, you tell me that one cake takes three and a half hours and four cakes take only half an hour more than one? It doesn’t make any sense!’ I though that she must be kidding so I started laughing.”

“But she wasn’t kidding?”

“No, she looked at me and said: ‘It makes perfect sense. This time is mostly waiting. And I can wait for many things at once just fine.’ I stopped laughing and started thinking. It finally started to get to me. Doing four pillows at the same time didn’t buy you any time, maybe it was arguably easier to organize but then again, maybe not. But this time it was something different. But I didn’t really know how to use that knowledge yet.”

“So grandma didn’t help you with the data center in the end?”

“Oh, she did. But it took some time. The problem was that I wasn’t waiting at work for anything, I was doing a lot of work all the time. During those years I was serving some computationally intensive tasks. I even did some experiments but as it turned out doing many things at once only made it all took longer. After all I had to do the same calculations anyway but I added more time for context switching. I didn’t see any value to parallelize my work. Until — ”

“Until what?”

“Until I started observing how other people worked. At that time we had to centralize our data in a single place. Various clients could get directed to different server every time they came to us, and that second server had to have access to the same data that the first one has stored. So in the back end we build a database department, a group of specialized servers who’s only job was to store and retrieve data for others.”

“Wouldn’t it mean more trips to the database in every request?”

“Yes, so we hired a lot of people who’s only job was to transfer packets between the main servers and the database. Now a server could get a request from a client and tell one of those new people to get some data from the database instead of going there himself. It helped because those messengers could get few requests from the servers before actually going there and get to the database once for a whole bunch of queries. And this was amazing.”

“Did it help a lot?”

“Not really. It saved some time but not that much. But it showed us something interesting. Now most of the main servers were usually sitting and doing nothing. They were waiting for messengers to come back with data. And the clients were waiting for the servers. Every now and then people in the lines got angry seeing servers doing nothing and seeing clients doing nothing.”

“Didn’t they get angry before?”

“No, because everyone looked busy. Servers were going to the database so there was no one behind the interface and everyone knew that the entire line had to wait. But now people in the lines saw clients staring and servers and servers staring at clients and it looked like no one was doing anything. We got a lot of complaints at that time, even if all stats showed that using the messengers shortened the lines.”

“So why do you say it was a good idea?”

“Because it showed us the place for improvements. We realized that we could have more lines than servers.”

“How? What’s the points of lines without servers?”

“Every server instead of waiting for the messenger could go to the next line, get a request, send another messenger and so on. Soon we redesigned the lines in such a way that every server had four lines all going to its main desk, but he kept four little tables where he temporarily kept everything needed to complete every one of the four requests that he processed concurrently.”

“Isn’t that more complicated than having a full desk for every line?”

“Yes it is, but it takes significantly less space. Not everything needs to be unique for every thread. A lot of resources can be shared by all of them.”

“Thread? What’s a thread?”

“This setup reminded me so much your grandma embroidering four pillows with four threads, switching context between one pillow to the other but still with one thimble and a single pair of scissors shared between all of them, only the thread was unique, that I insisted on calling all those lines going to the same process a thread.”

“Clever.”

“Yes, I know. Soon we also learnt how accurate that analogy was when we tried to scale the system using more threads per every process. There’s a reason why your grandma wasn’t embroidering dozens of pillow at a time. I asked her about it years later and she told me: ‘Because with so many threads it’s harder to keep them apart.’ I wish I had asked her that question sooner but I didn’t. We tried to scale our servers to more than 8 threads per process but with no luck. Eight seemed to be the number that worked best. Until it didn’t because the workflow changed and we saw that 4 threads are optimal. Then something around ten or twelve worked fine but for short periods of time. Usually we couldn’t handle more than 10 concurrent connections very well. We called it the C10k problem.”

“What does it stand for?”

“It’s concurrent ten konnektions problem.”

“But isn’t ‘connection’ spelled with ‘C’?”

“It is now. But getting the right number of threads wasn’t the hardest part.”

“And what was harder than that?”

“The harder part was moving the control between threads, the context switching as we called it. We hired a new kind of specialized workers called schedulers. Their job was to distribute threads across processors and telling them when it’s time to switch context.”

“Did it help?”

“Yes. But we realized that we get some processes or processors, as we thought was a more suitable term at this point, that had little work and a lot of waiting and constantly switching context between all of the threads didn’t help at all, if all of those threads are waiting anyway. And some of those threads were waiting indefinitely.”

“How is it possible?”

“Accidents happen. People die. That’s part of life. When people work in a big database it’s easy to fall a victim of a ton of papers falling on your head.”

“That’s scary.”

“That’s nothing. Everyone who works with big data knows that it means big danger.”

“I guess.”

“But the problem is when you are a process with eight threads all waiting for a messenger who got killed by a pile of big data. It can get unnoticed for years.”

“For years?”

“Yes. A man like me could get to the office in the morning, start doing his work as usual, switch context every time the scheduler tells him so and then go back home without doing any useful work at all. The only result of his presence at work was generating some papers in the trash, and that’s why some people called it trashing but it wasn’t a good name for that.”

“Why not?”

“Never mind, I’ll explain it later when I tell you about virtual memory. The point is that people who hadn’t been doing even a single useful thing for years tended to get violent, for some reason. We had quite a few accidents and we had to do something about it.”

“What did you do?”

“We observed how they behave themselves. It turned out that they developed their own ways to deal with the problem. They started drinking. When someone knew that he’ll need to wait a lot of time then he got drunk and passed out. When he woke up he usually had something to do and didn’t need to wait. It seemed like a win-win situation at first, until we started to see some problems.”

“What problems?”

“First it was just an increase of the number of errors. Then some minor violence. Finally we saw office equipment getting stolen and we knew we had to do something about it.”

“Did you forbid drinking at work?”

“Yes, we knew it was a drastic measure but we had no choice. But we knew that we needed to find something that would help with the waiting and yet wouldn’t impact the quality of work and user experience. And we found a perfect solution.”

“What?”

“We needed a substance that could make you instantly black out but keep you alive in a state from which you could be woken up in less than a second.

“Is there such a substance?”

“Yes, it turns out that unbiunium has exactly that effect. It solved all of the problems. We no longer cared how long we would have to wait for any operation because every time we sent a messenger we blacked out and were brought back to live by the messenger who got back with the answer. The messenger would black out waiting for the database. Eventually even clients in lines would black out for the time they were waiting. We called it blacking I/O.”

“Was it safe?”

“Perfectly safe. We used to wear collars with a supply of unbiunium so we could instantly administer the required dose and get it instantly deactivated by someone else who got back with our response. We had absolutely no experience of any waiting whatsoever. We had no recollection of waiting for I/O at all. From our perspective it was exactly as if the I/O was instant. If we needed some data, we asked for it and in the next instruction we could use it. At that point we were just like a real process.”

“Like a real process?”

“No, I mean we were real processes. Everyone was happy. No waiting. No frustration. No drinking. And the reasoning about the control flow was so easy. When you were planning your day at work you could plan that at one second you ask for some data, and the very next second you use that data. It didn’t matter that between those two conscious seconds there was a minute or an hour of waiting, because you didn’t experience any of it.”

“Sounds perfect, grandpa. By if the blacking I/O was so great then why did we need to invent the nonblacking I/O, then?”

“That’s a very good question. When people didn’t experience the waiting, they naturally tended to plan their routines as if the waiting didn’t happen at all. They didn’t see any difference between a task that gives you instant result and a task that gives you a result after an hour. Another problem was the storage of sleeping processes.”

“What storage?”

“While the process was sleeping we not only had to store that person in some safe place, but also all of his stuff, the entire desk, papers, everything.”

“Didn’t he already have the desk and everything?”

“Yes, but this place occasionally had to be reused by someone else. We had to move all of the stuff of sleeping processes somewhere else so other processes could work using the space once occupied by that sleeping process. We had to build an entire building for that. We called it swap area because we were swapping the processes that could be woken up with all of their data, for processes that was just blacking out. When we had so much swapping that we couldn’t do any real work between the swapping, we called it trashing.”

“Why trashing?”

“No reason. The important thing is that the panic started when people started dying in the swap area.”

“So the substance wasn’t that safe after all?”

“It was perfectly safe.”

“Why the dying then?”

“They were dying from the old age.”

“What?”

“Yes. When you execute a blacking operation you never know how long it would take and you have no way to do anything during the blackout.”

“Couldn’t you ask someone to wake you up after some time?”

“You could. There were people hired to do exactly that. We called them timeouts.”

“Why timeouts?”

“Timeout is short for time keeper of the blackout. Every time you invoked some blacking I/O operation you would schedule a timeout who would wake you up for example an hour later if the operation didn’t complete during that time.”

“Sounds like a perfect solution.”

“It was at first. People stopped worrying that they die waiting on I/O but soon it turned out that the usual process spent most of his life in a blacking state anyway. People stopped worrying if they wake up every time but when you do something for a minute and then again get blacked out for another hour, you still loose most of your life, even if not everything at once. Besides we had more processes sleeping and swapped out than we had those who were running.”

“Did you find a solution?”

“Your grandma did.”

“How?”

“We could no longer manage the data center. It was such a mess that people were losing their minds. I didn’t even tell you the scariest things that we experienced.”

“Like what?”

“Like the deadlocks.”

“What’s a deadlock?”

“You don’t want to know, trust me. I will just tell you that when most of our personnel was working on the swap area and managing semaphores and critical sections, we started to see the first acts of violence. And it was nothing like the deadly accidents that we were all used to. This time it was completely different.”

“How so?”

“People started bringing guns and knifes to work. Duels, revenge and vendetta were a part of life. Competing gangs started to form and fight with each other. There was a gang called Railwaymen who wore leather jackets with a golden semaphore. There were Dekker’s Devils. Peterson’s Angels. Atomic Isotopes. Fetch-and-add Dogs. Locksmiths from Hell. Most of them had Optimistic and Pessimistic fractions. It was a mess. Real mess.”

“Couldn’t you close the data center and throw them out?”

“No! Because there was no single person who understood how the data center worked any more! We needed all of them to operate. We had to tolerate the violent gang culture, we simply had no other choice. And then a tragedy happened.”

“What tragedy?”

“A real tragedy that no one has anticipated in the worst nightmares. A distributed deadlock killed most of the back-end workers and severely injured the rest of them. There were even victims at the front-end and among the clients. It was the end of the data center. We didn’t even know where to start fixing all that mess. The gangs were all killed but we didn’t understand the underground society that they created. The back-end was the biggest network of interconnected rules that I have ever seen. We didn’t even understand it any more.”

“But you said that grandma helped, right?”

“Yes, she did. I told her about the gangs and acts of violence. I couldn’t lie to her any more. Not with the stories all over the news and the riots on the streets. I told her that it was over. That the mess came to the point where it cannot be cleaned up any more. There was simply no hope.”

“And what did she say?”

“Oh, you know grandma. Have you ever seen her complaining?”

“No.”

“Have you ever seen her saying that something is hopeless and the chaos came to the point where you simply cannot clean the mess any more?”

“No. Never.”

“Exactly. She simply doesn’t comprehend the idea of hopeless mess. So she couldn’t possibly understand me. She told me that if we have a mess at work then we should start cleaning it up instead of finding excuses.”

“So did you start cleaning it up?”

“Of course not! I told her that it’s such a mess that it’s even impossible to decide where to start from. She told me we should fix one thing at a time. But I explained to her that that is the whole point, that we have a one monolithic mess. We can’t possibly fix one thing at a time if all we have is one thing!”

“So did she agree with you that it’s hopeless?”

“Of course not! It’s like she doesn’t even understand the very concept of hopelessness! Do you know what she told me?”

“What?”

“She told me that if I have one big mess that I cannot manage then I should divide it into smaller units that will be manageable. She told me that her great grandmother had a house cleaning company. But ‘house cleaning’ is such a broad service that she divided it into smaller units that she called microservices. And that’s what I did.”

“And you solved all the problems?”

“Not instantly. But instead of seeing one big mess, I started to see many small messes. I could pick any one of them and rewrite as an independent microservice. But that was just a method to split the mess. I knew that if we go the same route as before, there will be new gangs maybe even stronger than before. We needed simplicity. We needed an entirely different philosophy. But I didn’t know what it could be yet.”

“Did grandma help you with that?”

“She did. I told her that I modeled the entire data center on the model of her doing many things concurrently. I told her that the data center worked like grandma who was doing few things apparently at the same time by cycling between separate tasks such as baking a cake, making tea, washing clothes and washing dishes.”

“Was she surprised that you modeled the entire data center on her?”

“She didn’t seem to. She only told me that she didn’t work that way.”

“What?”

“Yes. I was shocked. But she told me that she didn’t constantly cycle between waiting for the water for tea to boil and the cake to get baked.”

“How so?”

“She doesn’t cycle between waiting for different things to finish.”

“Then what did she wait for first?”

“That’s exactly what I asked her. She told me that nothing and everything, but not anything in particular.”

“What?”

“I didn’t understand her, either. She explained that there is no time when she is actively waiting for anything. She does what she can to completion and then she waits for callbacks.”

“Callbacks?”

“Her great grandmother used that term. When she puts something into the oven and sets a timer, she stops caring about it. She doesn’t wait for the bell to ring when it’s baked. She just forgets about it, until it actually rings. When she puts clothes to the washing machine, she doesn’t wait for it to finish. She is completely free to think about anything and do anything, But a sudden silence of the washing machine reminds her to add ‘clothes washed’ event on her mental event loop, as she calls it.”

“Is that something she learned from her great grandmother?”

“Yes. When she hear the oven bell and the washing machine gets silent at the same time, she has two events to handle and she knows what to do. Those are simple things, like take the clothes out and take the cake out to cool down. The point is that she neither waits for one thing to finish, not does she switch the waiting between few things. She starts it and forgets about it, waiting for callbacks to remind her later.”

“Did you use that idea in the data center?”

“You bet I did! And why do you think that today you don’t wait in line when you send an e-mail to your friends?”

“You mean the p-mail?”

“Yes, of course. The people-mail. Obviously, we don’t have electronics.”

“We don’t have what?”

“Never mind. When you send a p-mail to your friend what do you do?”

“I put a piece of paper with his address and my address to get a response, into the slot at the data center.”

“Do you wait in line?”

“No, there are hundreds of slots and it takes a second so why would there be a line if I don’t wait for anything?”

“Exactly. And how do you get the information about your credit card debt? Do you wait in line to get to the server, and than wait until you get that data back?”

“Of course not! I put a piece of paper with my request and my address into the slot and I go home. Then when it’s ready my phone rings and I know that I can pick up the response that’s waiting for me in the place where I requested, usually in my inbox downstairs.”

“Yes, it’s a good thing that we don’t need silicon for analog telephony.”

“What does the silicon have to — ”

“Nothing. Do you wait for anything at any point?”

“Not in an active sense. There is no act of waiting that blocks me from doing anything else.”

“And that’s the whole point. You can thank your grandma for that.”

“For not waiting in lines?”

“This and not having violent gangs rioting on the streets and killing people.”

“Oh, right.”

“And that, my kid, is the essence of the nonblacking I/O on the planet Asynchronia256/16. We may not have silicon. But your grandmother surely knows how to bake a good cake!”

“She surely does. She surely does.”


Rafał Pocztarski is a Node.js developer based in Warsaw, Poland, who can be reached as @pocztarski on Twitter or other social networks listed on pocztarski.com. Every feedback is highly appreciated.

See also:

Show your support

Clapping shows how much you appreciated Rafał Pocztarski’s story.