🚀 go-pugleaf

peter@ferranti.com (peter da silva) writes:
> > OK, try this. VMS has something called an AST (Asynchronous System Trap) which
> > is similar to a user-mode interrupt.
> 
> Yes, I'm familiar with it from RMX.  There, at least, unless you're working
> in assembler it's something to be used with extreme care lest you trash the
> language runtime.

This is largely false in the VMS environment.  Language runtimes are mostly
reentrant; the big exception is the C runtime, which is a piece of crap
anyway.  (And in any case, the C runtime doesn't mind if you don't use any
of the non-reentrant code.  Only calling a non-reentrant routine from an
AST while the same or a related routine is also executing has problems.)

> > This may occur at any time: for instance,
> > an asynchronous I/O can call an AST routine when the I/O completes. When the
> > AST routine completes, control returns to the code that was executing at the
> > time the AST occurred. (The analogy in NT is the APC, or Asynchronous
> > Procedure Call.)
> 
> And in UNIX the analog is a "signal". Now, a signal is a little "safer" than
> an AST (at least as under RMX), in that it's guaranteed to run in your task
> context.

Unix signals are basically a small subset of AST functionality.  Signals
can be implemented in VMS using ASTs, but not vice-versa.

> > Now, much of the run-time stuff in UNIX is non-reentrant.
> 
> Much of the *C* run-time in *any* language is non-reentrant, and I would
> be surprised if the VMS library was any better. If I get an AST while I'm
> in the runtime (say, in the Fortran library in the middle of a formatted
> I/O statement) I would expect dire consequences from calling the language
> runtime. I have never written an asyncronous signal handler under any
> operating system (out of UNIX, RMX, AmigaOS, and RSX-11) where I didn't
> have to watch for that sort of thing. In RSX all you can do from an AST,
> pretty much, is access memory.

I think you'd find the FORTRAN library is fine for AST reentrancy.  I've
certainly never seen any problems related to non-reentrancy of library
routines.  (That doesn't say there are no gotchas lurking.) 

I mean, reentrancy is (or should be) a non-problem.  It's *not* hard to
write re-entrant code, particularly when you're dealling with interrupt
reentrancy (ie the routine interrupts, runs to completion and leaves
the mainline to continue) rather than multitasking or multiprocessing. 

The C library on Unix is non-reentrant because there wasn't much call 
for it (async code is mainly for exception processing, and usually results
in a longjmp() anyway; any seriously asynchronous stuff gets kicked into
a subprocess).  On VMS it's simply because the code is crap.

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052