[Info-vax] VMS Software Q1 '23 Update

[Dan Cross]

In article <trj666$1epo9$2 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 2/3/2023 8:58 AM, Dan Cross wrote:
>>> Isn't async build on top of threads?
>> 
>> No, not necessarily.  async can be used to build threads,
>> and async executors can run in threads, but the two are
>> in many ways duals of one another.
>
>It is two very different programming models.
>
>But the usual async await model is that it is syntactic
>sugar that under the hood creates a task that get scheduled
>to run in a thread pool.

You're conflating async/await and the executor model generally
with executors running in thread pools.  The two are separable,
and one can write a totally custom executor that runs completely
independently of an underlying thread abstraction.

> From as programming model perspective it is:
>
>async await - task and thread pool - raw threads
>
>But implementation wise it is different levels of abstraction:
>
>async await
>     |
>task and thread pool
>     |
>raw threads

Nope.  See above.

>For someone developing applications in Rust then the
>programming model is what is important.
>
>But for porting Rust compiler and runtime to a new OS,
>then the implementation matters.

I'm talking about the implementation.

There is no, "Rust Runtime" per se, which is one of the things
that makes it so pleasant for bare-metal and kernel development:
turn on the computer, get running wherever you're linked at, set
up a stack, and jump into Rust code.  For example, here's the
boot loader I wrote for our machines.  It runs from the x86
reset vector: https://github.com/oxidecomputer/phbl/

There _is_ a standard library, but how it's implemented varies
based on target.

>My expectation would be that if the OS expose a
>working pthreads C library then Rust could do
>async await on that platform as all the layers
>in between would work.

Pthreads, or any other such thread implementation, are not
required for async Rust to be implemented on a system.  For
example, look at "lilos", which is targeted towards
microcontrollers, and makes heavy use of `async`:
https://github.com/cbiffle/lilos/

System developers, e.g., those doing an OpenVMS port, may
_choose_ to run executors in terms of the underlying thread
primitives provided by the OS, but that's not at all required.

>Of course all this stuff is most useful if
>there is support for async IO. VMS most definitely
>support that. But depending on what Rust rely on
>then there may be a gap between what the Rust
>runtime expects and what VMS has.

Again, there is no, "Rust runtime" in the sense you're implying.

>Bridging *nix centric IO and VMS IO can be
>tricky. Just look at the Java IO on VMS
>mess.
>
>So I am not definitely not saying that getting
>Rust running on VMS will be easy.

I don't see why not, honestly.  Bringing over the standard
library may be a bit of work, but there's a Windows port and in
an ironic twist of fate, that may well serve as an example of
how to implement the VMS-specific bits.

	- Dan C.