Is asynchronous IPC preventing us from using parallelism?

[Solar]

Well, actually rdos has a point here too. Going for "completely different" has its merits, but being able to support existing technology isn't all bad either.

[NickJohnson]

Well, actually rdos has a point here too. Going for "completely different" has its merits, but being able to support existing technology isn't all bad either.

In my current project, I'm trying to write a network-capable system in as little time as possible. I've found that it's actually much easier to reason about a complex system like a TCP/IP stack (or block cache or pipe driver) when it is implemented as many asynchronous server threads using message passing, and as a result, that's how I'm implementing the whole kernel. However, I'm not trying to create any sort of special asynchronous I/O API for userspace; all of this is done in kernelspace. In fact, I'm just going to support a normal *nix system call API. In my mind, that doesn't negate the usefulness of a fully asynchronous architecture, because I'm using it as a software construction technique instead of an API paradigm. You need to support standard interfaces, or nobody is going to use your system, but that doesn't mean you are inherently paving over all the benefits of your design. If I can build and extend my system faster than you can yours, I still win, even if our APIs are the same.

[OSwhatever]

QNX usually brags about being fully POSIX compilant and it is definitely as selling point. There is a large code base out there using POSIX calls and if we want to add extra functionality we can always to add that coexisting with POSIX. I remember one job I had implementing a file system for a client. I had made up my own file system calls but when I got to the client it said it wanted POSIX calls. I had no choice other than add it. We shouldn't underestimate how conservative programmers are and that they want something they can recognize. This forum might be about not being conservative but out in the business world where money talks giving the customers what they want usually mean what they already are accustomed to.

[NickJohnson]

Even if you don't have customers to satisfy, I'd say it still makes sense to have compatibility. What I'm after with *nix compatibility is the massive base of existing code that will be trivial to port. I may very well come up with a new API for new code eventually, but the point is getting off the ground quickly. In my opinion, that's the best way to create a new system: construct an architecture that will support the standard interface (even if it is inefficient), then port lots of things to attract new users and developers (because to any non-kernel-hacker, an OS is only as good as what runs on it), and only then create a new/interesting/efficient API and start rewriting the userland.

[Solar]

Even if you don't look at Firefox, LibreOffice and Gimp - if you want C/C++, Perl, Python and Java, you'd better not go completely crazy with non-compatibility.

Then again, if you don't want any of that, do what thou wilst...

[Combuster]

The main problem with all this is that people haven't learned to do asynchronous file I/O.

libc is synchronous, jre is synchronous, posix is synchronous, w32 is synchronous. And it repeatedly happens that those very systems lock up the moment there's something wrong in the I/O layer. Even the windows desktop still locks up the moment you try accessing a network share when it's offline. Heck, I had a linux kernel deadlock a week ago because of that.

If you want some quality as a feature in return, you might as well decide to force your developers to do things right and purposefully not provide the legacy mechanisms. I'm pretty sure that is exactly what Brendan's been doing these past years.

[Colonel Kernel]

libc is synchronous, jre is synchronous, posix is synchronous, w32 is synchronous.

Win32 has supported asynchronous I/O since the very beginning. The problem is that it's been so difficult to use that most developers haven't bothered. Structuring all your code using callbacks is a pain. C#'s new async/await keywords should alleviate a lot of that pain, at least for .NET developers.

[NickJohnson]

If you want some quality as a feature in return, you might as well decide to force your developers to do things right and purposefully not provide the legacy mechanisms. I'm pretty sure that is exactly what Brendan's been doing these past years.

It seems sort of silly to design a whole new OS around that idea though, since existing systems already support asynchronous I/O in some form or another. What is really needed is a framework for building highly concurrent/asynchronous applications that simplifies the use of asynchronous I/O, so that developers will actually design programs that way. I've had at least partial success doing that in C (with a good dose of stack magic and macros) in my current project, and I imagine it could be done more cleanly in C++. The point is, it doesn't need to be a kernel API; it can just be a library.

[Colonel Kernel]

It seems sort of silly to design a whole new OS around that idea though, since existing systems already support asynchronous I/O in some form or another. What is really needed is a framework for building highly concurrent/asynchronous applications that simplifies the use of asynchronous I/O, so that developers will actually design programs that way. I've had at least partial success doing that in C (with a good dose of stack magic and macros) in my current project, and I imagine it could be done more cleanly in C++. The point is, it doesn't need to be a kernel API; it can just be a library.

C# will elegantly solve this problem (full example here: http://msdn.microsoft.com/en-us/library ... .110).aspx):

Code: Select all

private async Task<byte[]> GetURLContentsAsync(string url)
{
    // The downloaded resource ends up in the variable named content.
    var content = new MemoryStream();

    // Initialize an HttpWebRequest for the current URL.
    var webReq = (HttpWebRequest)WebRequest.Create(url);

    // **Call GetResponseAsync instead of GetResponse, and await the result.
    // GetResponseAsync returns a Task<WebResponse>.
    using (WebResponse response = await webReq.GetResponseAsync())
    {
        // Get the data stream that is associated with the specified URL.
        using (Stream responseStream = response.GetResponseStream())
        {
            // ** Call CopyToAsync instead of CopyTo, and await the response.
            // CopyToAsync returns a Task, not a Task<T>.
            await responseStream.CopyToAsync(content);
        }
    }
    // Return the result as a byte array.
    return content.ToArray();
}

It looks synchronous, but under the hood the compiler is turning everything after each "await" into a continuation, so it's fully asynchronous. Any method marked as "async" can be "awaited", meaning this is fully composable.

[Combuster]

Win32 has supported asynchronous I/O since the very beginning

EDIT: <deleted> Turns out Microsoft 1984'd its documentation. The win32 API no longer exists in anything older than Windows XP.

[gerryg400]

I suspect, though I'm not sure, that it wouldn't hurt server performance for a server to support both synchronous and asynchronous clients. In fact I don't think the server need know whether the client is synch or asynch as long as the server 'reply' call doesn't block.

So is there a problem with supporting both paradigms ?

[Ready4Dis]

I suspect, though I'm not sure, that it wouldn't hurt server performance for a server to support both synchronous and asynchronous clients. In fact I don't think the server need know whether the client is synch or asynch as long as the server 'reply' call doesn't block.

So is there a problem with supporting both paradigms ?

Yes, there is a problem. If you give a developer the opportunity to write all new interface code, or simply re-compile an existing program that just works, which would they choose? Duh, obviuosly the easiest method, even if it is the slower of the two, and could cause a few hang-up issues, why re-invent the wheel. The point is, once you give anybody an easy way out, they are going to take it and completely ignore the harder route even if it is a bit more rewarding in the end.

[gerryg400]

Yes, there is a problem. If you give a developer the opportunity to write all new interface code, or simply re-compile an existing program that just works, which would they choose? Duh, obviuosly the easiest method, even if it is the slower of the two, and could cause a few hang-up issues, why re-invent the wheel. The point is, once you give anybody an easy way out, they are going to take it and completely ignore the harder route even if it is a bit more rewarding in the end.

I don't see that as a problem. Well not a problem for me the OS designer. Providing different ways to do things in different circumstances would be an advantage.

What I was wondering was whether it would be a problem for the server. Would it even need to know that both interfaces are supported ?

[Solar]

If you give a developer the opportunity to write all new interface code, or simply re-compile an existing program that just works, which would they choose? Duh, obviuosly the easiest method, even if it is the slower of the two, and could cause a few hang-up issues, why re-invent the wheel. The point is, once you give anybody an easy way out, they are going to take it and completely ignore the harder route even if it is a bit more rewarding in the end.

That's like actively disallowing C/C++ on a machine because Java and Python are "better": Cutting off your nose to spite your face...

[Ready4Dis]

If you give a developer the opportunity to write all new interface code, or simply re-compile an existing program that just works, which would they choose? Duh, obviuosly the easiest method, even if it is the slower of the two, and could cause a few hang-up issues, why re-invent the wheel. The point is, once you give anybody an easy way out, they are going to take it and completely ignore the harder route even if it is a bit more rewarding in the end.

That's like actively disallowing C/C++ on a machine because Java and Python are "better": Cutting off your nose to spite your face...

No, you are comparing a language to an api, they are two different things. Different langauges have different uses, and some are 'better' at some things, while others are better for other things. If you made a new graphics api, but also supported opengl, who would port a game to your api and who would just stick with opengl since it requires no changes to their code, even if its a tiny bit slower... It has nothing to do with c vs. java. I don't agree or disagree with including or discluding posix interface. Its his os, and he wants what he wants. If he wanted another *nix, he could just use linux. He wants to force people to use a more efficient api, rather than stick with backward compatibility, I see nothing wrong with that. If you want *nix compatibility in your os, go for it. He doesn't want yet another nix clone, there are plenty of those. The point of wiring his own os is to do something different, so I commend him in his efforts and wish him luck.