World: r3wp

The advantage of this is that you should be able to do really simple 
shortcuts for some operations.

R2-style:
db: open odbc://server
dbc: first db
insert dbc "select * from catalog.schema.object"
copy dbc

R3 style:
read/lines odbc://server/catalog.schema.object

Plus, with R3-style you could write asynchronous stuff that the R2 
style doesn't do.

Your rejection of R3 style is what your block scheme infamous, and 
fun too :)

the asyncrhonous stuff is doable only if one start GUI do-event loop.
Quite limited

Not the GUI event loop, the event loop. Which is as simple as WAIT 
port.

Your block scheme probably wouldn't have benefited from asynchronicity 
that much. Or would it have? That would be interesting to find out.

Async was pretty limited in R2 because you had to start the GUI event 
loop, which only the View builds had. With R3, even core has an event 
loop, and a lot of stuff uses it.

My scheme only open regular files (not a messaging pipe)

It would be interesting to see if there would be a way to make an 
async file scheme using the async or non-blocking file APIs of various 
operating systems. This would be needed to support WinRT-based applications 
for Windows 8, for instance.

I'm sure Linux, Mac and such have non-blocking I/O APIs too.

I think R3 is too slow to benefit of such non blocking API.

It makes sense wh

It makes sense when dealing with network connections but not with 
the file system IMHO

It makes sense for Node.js, and would make sense for other compiled 
languages like Red and World. I suppose Topaz could build an R3-style 
port model on top of Node.js as well.

Disk I/O pauses are becoming something that people complain about, 
like GC pauses. Only if it's faster or easier to use though.

in R3, I noticed yh

In R3, I noticed that the GC combined with the BALLAST option can 
erase the pause syndrom

It increase the GC refreshing rate and makes the pauses shorter

Nice. I meant industry-wide, but it's good to hear that there's help 
for R3.

Following the Win8 announcements, one of the interesting things is 
that WinRT, the new runtime, doesn't have blocking APIs. Only async.

File I/O can be pretty slow in some cases nowadays, particularly 
for accessing SD cards. I get freezes with AltME pretty often because 
of it waiting for blocking calls.

Not only that, Altme has lot of rooms for speed improvements  :)

funny thing is that single most effective way to increase disk I/O 
on windows 7 is to make all transfers non Async  :-)

it has been reported as being as much as 50% faster though all the 
explorer reporting becomes totally wrong... i.e. instead of wasting 
time trying to determine how fast and how much time it takes, it 
just does its copy and reporting is completely off, but its actually 
much faster.

Sounds like a trade-off between throughput and responsiveness