OSDev.org

Solar wrote: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.

Combuster wrote:libc is synchronous, jre is synchronous, posix is synchronous, w32 is synchronous.

Combuster wrote: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.

NickJohnson wrote: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.

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();
}

Win32 has supported asynchronous I/O since the very beginning

gerryg400 wrote: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 wrote: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.

Ready4Dis wrote: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.

Solar wrote:

Ready4Dis wrote: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...