The Place to Start for Operating System Developers
https://f.osdev.org/
I absolutely disagree with that. If you have a server that handles thousands of simultaneous requests you don't want to create a thread context for each client. This is where asynchronous IO shines and you let the operating system services handle the data asynchronously as it is being received/transferred without the extra memory overhead.nullplan wrote:No, the correct way to do async IO is not to do it at all, but rather use synchronous IO in multiple threads. This also allows for simpler control flow. The only other way to do async IO is to separate the data input path from the data output path (main loop switches between handling read and write). But this only requires a way to test for whether data is ready to be read. Which can also be done with a read() call on a socket that was set to nonblocking, and otherwise only requires a way to sleep until a time has elapsed or data is ready, which select() provides, but so do other things.
Any of that.eekee wrote:I'm a little confused on what async IO actually is, especially when reading. After requesting to read some data, do you poll for it later, or is it delivered by callback, or what?
It depends on the application.Code: Select all
ReadFile(..., (data) => {
WriteFile(..., () => {
ReadFile(..., (data) => {
});
});
});
Code: Select all
ReadFile(...).then((data) => {
return WriteFile(..);
}).then(() => {
return ReadFile();
}).then((data) => {
});
Code: Select all
data = await ReadFile(...);
await WriteFile(...);
data = await ReadFile(...);
Code: Select all
future_data = MakeFuture(() => {
data = ReadFile(...);
WriteFile(...);
return ReadFile(...);
});
....
data = future_data.get();
Thanks. I love that article, it's very entertaining to a renegade Wikipedian!iansjack wrote:https://en.wikipedia.org/wiki/Asynchronous_I/O
It's absolutely terrible by Wikipedia standards, but there's some info I recognize as good. So the answer is, "It's all the things, even almost all of the things people refer to as synchronous IO." Okay then.The exact point at which such async IO becomes worthwhile will depend how 'heavy' your thread model is. This raises some questions which might be interesting if they're not too deep even for this board. Also worth remembering: 1000 simultaneous requests was achieved with asyc IO in the 90s. I'm sure modern systems could handle a few thousand without it.OSwhatever wrote:If you have a server that handles thousands of simultaneous requests you don't want to create a thread context for each client. This is where asynchronous IO shines and you let the operating system services handle the data asynchronously as it is being received/transferred without the extra memory overhead.
An inlined function in a very pseudo-Javascripty way.eekee wrote:I understand most of the syntax, but what does => do?
Code: Select all
(function param 1, function param 2 ) => {
// Function body
}