[Info-vax] LLVM, volatile and async VMS I/O and system calls

[Lawrence D’Oliveiro]

On Friday, September 24, 2021 at 3:23:02 PM UTC+12, Stephen Hoffman wrote:

> At the level being discussed ($io_perform, $qio) all I/O is async by 
> default. The app queues the I/O request, and goes off to do... 
> whatever.

Coming from VMS, where I/O and process scheduling were inherently decoupled, I find the Unix way a step backwards in some ways. Linux has its “aio” framework, but that seems to be specifically for block devices, for use it seems by some DBMS implementors who don’t like to work through conventional filesystems.

> Language-based async/await is not something that was common in years 
> past ...

It’s just a revival of the old coroutine concept from decades past. Kind of. There is this terminology of “stackful” versus “stackless” coroutines, where the original kind was “stackful”. Async/await are described as “stackless” because they don’t need to switch entire stacks between tasks, since preemption can only occur at limited points. Perhaps more accurately described as “stack-light”, but there you go.

> select is a mess on OpenVMS, so we won't discuss that.

No “poll” or “epoll” ... ? “select” is considered a bit old-fashioned these days...

> Creating an app that's basically one big ball of self-requeuing ASTs 
> with a main that hibernates and wakes works pretty well for 
> low-to-moderate-scale OpenVMS apps, too. 

I did that once, back in my MSc days. I also wrote my own threading package on top of ASTs, and tried reimplementing the app on top of that. Performance dropped by half.