Is asynchronous IPC preventing us from using parallelism?

[Owen]

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.

NT had asynchronous IO before synchronous IO was implemented. That said, they implemented synchronous IO at the system call level before first release.

Win32s, Win95 and co all ignored asynchronous IO because it didn't really fit into their driver model. Therefore, it didn't get used in 9x originated applications, which is why Explorer is fundamentally built upon Synchronous IO. That all said, Explorer at least has the redeeming feature that each window (and the desktop) runs in its own thread; Thankfully, only one window locks up.

Citation

[Solar]

No, you are comparing a language to an api, they are two different things.

As if I didn't know that. I didn't "compare" them, I tried to illustrate a point.

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...

Do you realize how you are contradicting yourself within two consecutive sentences?

If you provide a new API that is significantly different from the already existing, well-established one, it will be better at some things, and the established one better at other things. I agree with that.

In which case, there is absolutely no need to not support both APIs on your system. People doing one thing will use your new API, people doing other things will use the established API.

It's OK if you don't have the time to support an established API on your system alongside your new approach. That's certainly understandable.

But not supporting a well-established APIs on purpose in order to force people to use your API is an all-around dumb move. You can get away with it if you're Microsoft, or the FSF, but if you are in a position where you still want to attract developers (instead of locking them in), you should provide choice, not force-feed things to people.

[NickJohnson]

But not supporting a well-established APIs on purpose in order to force people to use your API is an all-around dumb move. You can get away with it if you're Microsoft, or the FSF, but if you are in a position where you still want to attract developers (instead of locking them in), you should provide choice, not force-feed things to people.

Even Microsoft supports some well-established APIs. It's the first step in "embrace, extend, extinguish."

[Colonel Kernel]

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 ?

Nope. The services I work on in .NET are internally async, but are used by both synchronous and asynchronous clients. The server is none the wiser. It has "BeginDoXyz" and "EndDoXyz" calls, but synchronous clients see it as "DoXyz".

Re: All the discussion around OSes purposefully not offering synchronous APIs: Not sure if anyone has looked at Win RT yet, but it only supports synchronous APIs where the calls are guaranteed to return quickly (less than 50 ms I think). So most I/O is async in the new APIs. The same is true for Silverlight.

[Combuster]

Even Microsoft supports some well-established APIs. It's the first step in "embrace, extend, extinguish."

And if you do provide them posix, they will port all the tools over, then demonstrate that linux is essentially the same but way better, no? So much for "embrace, extend extinguish"

At any rate, Apple pretty much requires developers to use Objective-C to be able to make quality programs, Google demands Java, and Microsoft is fixing on C# for everything but their desktops. That leaves only the FSF that concerns itself with portability - which is essentially a form of portability with itself. Heck, I even heard from the console industry insiders that Nintendo lacks a functioning malloc().

In essence, I think the entire portability thing is already slowly getting moot when it comes to end users - you know, the kind that think the console is an arcane device of white-on-black magic. Writing programs twice over is becoming normal.

And that's about as far as I can go on a rant without breaking NDAs.

[Ready4Dis]

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...

Do you realize how you are contradicting yourself within two consecutive sentences?

If you provide a new API that is significantly different from the already existing, well-established one, it will be better at some things, and the established one better at other things. I agree with that.

In which case, there is absolutely no need to not support both APIs on your system. People doing one thing will use your new API, people doing other things will use the established API.

It's OK if you don't have the time to support an established API on your system alongside your new approach. That's certainly understandable.

But not supporting a well-established APIs on purpose in order to force people to use your API is an all-around dumb move. You can get away with it if you're Microsoft, or the FSF, but if you are in a position where you still want to attract developers (instead of locking them in), you should provide choice, not force-feed things to people.

First off, it is not I who is designing this, nor did I start this topic, but I can appreciate his design decisions and reasoning. His entire design of his kernel is based around async calls, to put a layer over top that is synchronous will slow down his system. It will not be better at anything as you alluded to, it will be worse (or in best case, evenly matched), so the comparison does not hold true. To force people to use the more efficient method means that all applications written will be running more efficiently, rather than wasting resources trying to keep compatibility. Yes, having a compatibility layer would allow more applications to be easily ported, but if we all wanted the easy way out, we wouldn't be writing OS's. And if he's trying to go about the design in a different manner than you, it does not automatically make it an 'all-around dumb move'. He has a plan with a legitimate reason, which is more than I can say for most people that just try to build in compatibility first, then try to come up with novel ideas later to help their OS stand out (which never happens because they are so worried about compatibility that it just ends up being another *nix clone). There is nothing stopping anybody from writing a small compatibility library, but why should he be worried about it? It's his design for a specific reason, and I applaud him for going his own way. I don't know if it's the best idea or not, but if someone knew the best way to do everything, we wouldn't be having discussions on mono vs. micro, synch vs. async, etc, because what is the best for one, is not the best for everyone. If his design is a fully async model designed for handling many server connections, trying to put a ton of blocking threads overtop of it will not be better in any way, and will actually run worse than on other systems. If you allow programs to run that much slower on your OS than others, why would anyone want to develop for your OS since it's perceived as slow. If you only allow efficient apps, it will show from the start that your OS isn't slow, and get it more noticed and be able to do actual comparisons of apps written for your OS vs another that was specifically written for that type. As I said, I don't know if it's the best idea or not, nobody has actually done it and returned here with any real data, but at least he's trying.

[Solar]

*sigh*

It's OK if you don't have the time to support an established API on your system alongside your new approach. That's certainly understandable.

I probably should have said that it's also OK to not support compatibility APIs if they would require compromising your design. The only thing I spoke up against is somehow actively discouraging other APIs.

For example, Microsoft sure doesn't care about Cygwin one bit. But they don't actively combat running Cygwin on their machines, do they?

[Combuster]

Microsoft has little to do about cygwin, and they have enough issues of their own to deal with. Meanwhile at Apple...

Because the original is behind Apples paywall: Requirements for iPhone apps. In particular rules like

Apps that browse the web must use the iOS WebKit framework and WebKit Javascript

can be explained as actively prohibiting firefox and chrome, as well as

Apps with metadata that mentions the name of any other mobile platform will be rejected

being a stab at freedom of speech.

[bewing]

I agree with Solar and Brendan mostly. It's best to support both, unless you are intending to forge an entirely new paradigm.

I don't know where OS developers get the notion that other SW developers are going to do their work for them. If you want 'piece of software X' to eventually run natively on your custom API -- then *you* are the one who is going to have to do the work of porting it. Attempting to coerce anything will result in dead silence. In the meantime, it's best if that nice piece of software will run at all on your system. Which means supporting standard old crappy stuff like POSIX in some fashion or other. Once you have done the porting job to your API, you can demonstrate how much better it all works. THEN you will start to win converts.

Which brings me to Combuster's point -- all GUI programs have message loops. If porting a POSIX proggie to your API requires you to add a couple lines to the 'switch' of the message loop, that's not a very high price to add native API compatibility. But when you design your API you should keep in mind that you are the poor sucker who's going to be doing all the porting, so you'd better make it as easy as possible.