Conference azur::mcc

322.0. "Callable interface to MCC common routines" by PETE::BURGESS () Wed Sep 12 1990 10:21

A couple of points for developers to remember
about using "callable mcc" on VMS:

1.  What is "callable MCC"?

    The linker images, transfer vectors, and initialization code
    of DECmcc was modified last winter to enable developers to
    access the DECmcc common routines using standard VMS shareable
    library techniques.  

    The advantage is that client code is freed from the AM, FM, PM
    architectural constraints but certains run-time restrictions still remain.


2. Is there a not "callable MCC"? 
	
	No.  There is only one VMS packaging of the MCC common routines.
	 
    	The underlying image structure and application environment 
    	is the same for DECmcc and all other applications.

    linking rules-
	Given: A VMS shared image named mcc_kernel_shr.exe
	contains a set of universal symbols for standard VMS vectors
	for the MCC common routines defined in chapter 11
	of the SRM.

	All VMS executable images which use the DECmcc
	common routines must at least
	(1) include the object module mcc_kernel_initialize.obj
	(2) link with mcc_kernel_shr.exe


	All VMS shareable images which use the DECmcc common routines (XMs)
	must at least
	(1) link with mcc_kernel_shr.exe

    execution rules-
	For the MCC common routines to work as specified in the SRM
	it is recommended that the client code follow the good neighbor rules
	specified in the SRM.

3. What is the function of the module, mcc_kernel_initialize.obj?

	It is used to provide automatic initialization of the
	DECmcc framework environment during the image initialization
	process.  See chapter 7 of the LIBRTL manual about lib$initialize.

	The kernel initialization performs
		o If the debugger is not activated, then the p1 system vectors
		  for RMS routines and some composite system services (ie those
		  which are composed of a asynch service followed by sys$synch)
		  are patched to revector to the MCC thread synchronous version
		  of the routine (sys$qiow, sys$dnsw)

		o A condition handler is established 
		  which reports messages via sys$putmsg, and
		  if the severity of the signal if fatal,
		  then it requests CHF to unwind the call stack (ie abort the image)
		  else it requests CHF to continue from the signal.

		o It initializes the thread data structures, 
		  creates a thread context for the current pc (poof, you are now a thread)
		  and creates a null/scheduler thread.

4. Does my code in my application really need to follow the "good neighbor rules"?

    Absolute restrictions:
    	o.  The MCC common routines are not AST-entrant.  Therefore the
    	    MCC common routines in the SRM can *not* be reliably called from AST level of
    	    execution.  (Or from a condition handler)


    Possible restrictions:

    	o Your code may effect scheduling of threads:

	    The mcc thread scheduler currently (not forever) uses a "run-until-blocked
	    (by a mcc-framework service)" algorithm.   This is not a pre-emptive
	    scheduler.  If your code issues a sys$hibr, sys$synch, sys$(wait for event flag)
	    etc.  then your code will block the entire process.  This might be a problem.