Conference azur::mcc

I still feel quite ignorant around here, so hopefully someone will confirm 
my feelings:

The purpose of the AM is to talk to the entity in whatever manner the entity
wants to be talked to.  The AM is there to make access to the entity 
transparent to the caller.  The AM is free to use whatever communications 
mechanism is best suited to talking to its entity.  IPC certainly sounds 
like a good choice.

-	stp

    
    
    
    
>   The purpose of the AM is to talk to the entity in whatever manner the
>   entity wants to be talked to. 
    
    That is certainly 1 purpose of the AM.
    
>   The AM is there to make access to the entity transparent to the caller.  
    
    Yes.
    
>   The AM is free to use whatever communications mechanism is best suited 
>   to talking to its entity.
    
    No.  Remember that the AM executes in the context of a single thread, 
    managed by the mcc kernel.  There may be MANY threads within the
    process, all competing for scheduling, etc.  You must signal the kernel
    that your thread should be "released" while your I/O is pending.  This
    is done by using the kernel "monitor" routines, like MCC$QIOW.  I don't
    know if the kernel supports $IPC, but in general, you can't just "do
    anything".
    
    Cheers,
    Mike
    
                                                             
    

I understand that I can't use IPC for the moment!

Could someone tell me if there are any plans to support IPC in the MCC kernel ?


			-- Paul

    Yes,  I do have plans (though not bound to a committed schedule) to
    enable developers to use $IPCW within the constraints of the current
    multithreading environment.  
    
    There might be two choices of implementation:
    MCC$IPCW (...) which provides a thread-synchronous shell
    around $IPC and hides the non-portable AST operations;
    
    and revectoring $IPCW to invoke the MCC implementation
    of $IPCW (described above).  
    
    I would prefer to implement the second solution so that
    the client's interface is independent of the MCC threads package
    
    
    
    The NME project implementing DNA5 AM also wants a thread-synchronous
    $IPC-interface.
    
    

Thanks for the answer, but is it nevertheless possible to have an idea of a
reasonnable not-yet-committed schedule ?
(to see if it fits into my shortly-to-be-committed AM development)

Many thanks,

			-- Paul

    This is a futures consideration, but FWIW the IPC facility is VMS
    specific and is something that will need (major) conversion if
    your MM is ever to run on multiple platforms.  A better approach
    might be to take the existing already sort-of portable MCC$DA routines
    and use them to front end a number of transports (IPC might be
    one on VMS).  
    
    

	I found this note only recently after we had already committed 
	ourselves to delivering an access module which uses a messaging 
	system based on IPC as its underlying transport mechanism.

	Can someone please give me an update on .4.  Has this been 
	considered any further?  If we continue using IPC, what are
	the consequences?

	Regards,

	Alan

	
	
	The code to revector sys$ipcw to a mcc thread synchronous
	routine has not been sufficiently tested in time to be enabled
	for the MCC v1.1 kit.

	MCC v1.2 will solve the problem.

	
	Until you receive mcc v1.2, your code which uses sys$ipcw
	will block the process until the i/o is complete and during
	this interval no other threads will run - much like 
	cpu intensive rtn.  This may or may not pose a serious problem.
	

	Multi-threading has been used rather sparingly in MCC to-date:
		Iconic map pm uses multiple threads,
		each alarm rule enabled in the process creates a thread,
		notification services generates threads

	The execution of these potential threads would be delayed while
	your sys$ipcw completes.




	If you find that your project is jepodized by the temporary 
	interaction of MCC and sys$ipcw, then please contact me via mail.

	Pete Burgess