dbTalk Databases Forums  

Asynchronous system trap terminology nagging

comp.databases.oracle.server comp.databases.oracle.server


Discuss Asynchronous system trap terminology nagging in the comp.databases.oracle.server forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Mladen Gogala
 
Posts: n/a

Default Asynchronous system trap terminology nagging - 01-18-2012 , 09:58 AM






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 Ctrl-
C. 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.



--
http://mgogala.freehostia.com

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.