Asynchronous system trap terminology nagging

From: Mladen Gogala <>
Date: Wed, 18 Jan 2012 15:58:54 +0000 (UTC)
Message-ID: <jf6q7u$ul2$>

It seems that the term AST has somehow found its legitimacy in the Oracle internals texts. AST is a term coming from the long deceased OS called
"VMS". The abbreviation "AST" stands for "asynchronous system trap". This
sounds much like Unix/Linux signal delivery, but the similarity is only skin deep. Unix/Linux system delivery queues messages for the process to the process header in the .u area. Process will read those messages when it receives the next CPU quantum, or in plain English, the next time it is scheduled. Process will read those messages and invoke the appropriate handler for each message. There is nothing special about that. AST, on the other hand, worked in a completely different way. AST elevated the CPU IPL (interrupt priority level) and executed a code delivered by AST in the context of the targeted process. In other words, it was possible to write your own code and execute it in the context of another process. This was used for many pranks and jokes, when the delivered code wrote profanities on the SYS$OUTPUT, the artist known as STDOUT in Unix/Linux world. Ramifications of delivering your own code to another process were numerous and this mechanism was widely used by Oracle Corp., among others. This mechanism eventually gave birth to the "microkernel" system, because it is possible to have external mechanisms for virtual memory or disk I/O, working by delivering an external code to the process. Standard Unix/Linux system cannot do AST. There is no way for one process to deliver its own code to another process in the wonderful world of Unix. What Unix/Linux systems do is signal delivery, described earlier. Every process can read messages when it's scheduled and automagically invoke the
"handling routines". Signals are asynchronous because they are delivered
to the process by an external component, like the operator pressing CtrlC.  Unix/Linux process can and will execute predefined routines aka
"handlers" when the message is received, but the code must be present at
the compilation time. Again, there is no way for one Unix process to execute its own code in the context of another process. That makes signal delivery mechanism radically different from the VMS AST delivery mechanism. There were numerous ramifications, elevating IPL also blocked paging and scheduling events. AST philosophy was fairly complex, as opposed to much simpler and much more streamlined signal delivery mechanism.
I do object to using terms like AST or BAST in the context of Unix/Linux. BAST or "blocking AST" was a type of AST that prevented the delivery of other ASTs for the duration of the AST code. The term BAST is, therefore a grossly misleading and mystifying term for signal delivery, which has almost nothing in common with the original VMS AST delivery system. Unix/Linux systems use messaging. The "message handlers" are not delivered by the message sending process, they must be contained within the message recipient. Using the term AST only makes rather simple communication protocol murkier and less understandable, at least in my humble opinion.
Received on Wed Jan 18 2012 - 09:58:54 CST

Original text of this message