Conference azur::mcc

> 
> We have developed an AM which communicates with an agent represented by
> a VMS process using mailboxes and QIOWs. 
> 
> The communication is secured using locks to test if the listener is still there
> to read in the mailbox.
> 
> Anyway there is still a small time window inside which the listener may
> disappear letting the sender hanged on the QIOW write. This has been solved
> when the disappearance is due to a CTRL-C, because the listener (AM) is called
> again with handle state of CANCEL , so that we (AM) can give the sender a
> chance to exit its QIOW (and also clean the mailbox buffer).
> 
> My question is about CTRL-Y or anything abrupt such as stop/id or ... :
> 
> Does MCC issue in this case an alert to all pending threads ?
> 
> Is MCC even supposed to do it ?
> 

Exit processing on VMS has varying degrees of guarantees
 which approach BUT never reach 100% probability of being executed correctly.

(On Ultrix there seems to be one degree:   %0 Probability.
which forces cleanup to be done either on startup
or by other interested parties that are still around)

	Degree 1:  MCC alerts threads and waits for threads to complete
		   Risk:  some rogue thread never completes.
			  So user hits control-y ... and recursive flow
	
	Degree 2:  VMS Exit handlers.  Bypassed if Last chance handler is called
		   after a stack clobber/etc; bypassed if Stop/id; bypassed
		   if    debug32> quit <cr>

	Degree 3:  Kernel mode rundown handlers.  Used for RMS closing of files,
		   MCC user-written system services.


MCC inteprets Ctrl/y as a strong user request to delete the image:
	no threads are alerted.
	the out-of-band- AST routine performs sys$exit
		so that the image exit-handlers are called in fifo order,
		etc (see description of sys$exit)

	while the SRM discourages MMs from declaring exit handlers
	(bugs, possible timing problems, non-portability etc) you could 
	try it (though how is your AM going to signal the AGENT?)

> And surely not a MCC question : 
> 
> What is the effect of the loss of the listener on the QIOW of the sender :
> is the channel closed, does it send an abort or whatever ?
> 
> 
	This is the problem with VMS mailboxes for your application.
	The mailbox quotas may be reached, the sender is blocked trying
	to write to the full mailbox, hoping that the listener will
	read a few messages, emptying the mailbox so that the sender's
	write may complete.

	When the reader process/image is deleted, then the writer is
	still blocked- VMS never will signal the writer in any way.

	On the plus side, you can spin up a reader a day later
	and read the next message, etcs.


	VMS design style is generally to have some timeout/failure indicator
	reported by the either party.


Do you control the code on both sides of the mailbox?
	Your agent might set  sys$setrwm (watflg = 1)
	before its mbx writes so that qios are not blocked
	during resource waits. Or some other mechanism
	to avoid trying to write forever (a simple $setimr
	request concurrent with the qiow,

	a dead-man lock protocol:
		each parties creates and enques an exclusive lock mode on a resource
		representing themselves;  Other interested parties enque an exclusive
		lock request on the lock...when the lock request completes you know
		that the originator is dead(since his exclusive lock is gone).
	


Sort of a rambling reply but 
(1) VMS mbx i/o protocol can often lead to hung/blocked processes
    if a client/server process fails

(2) MCC (and VMS) exit handling does not offer 100% guarantee of 
    success.

Pete

You answer was exactly what I expected (/ feared) ...

A few precisions : we use your "dead-man lock protocol", we do not use mailboxes
to do flow control : I mean there can be only one request/response pending in 
the mailbox buffer.

So, if I understand well, the only safe solution is : using a timer and test if
the lock of the listener still exist when the timer expires, and if not
clean the QIOW.

Thanks again and regards

Pierre.

    This may be opening up a whole new can of worms, but I have to give it
    a shot.
    
    Have you considered using MCC events instead of mailboxes?  The sender
    calls mcc_event_put() and the listener calls mcc_event_get().  These
    routines are fully thread synchronous and conform to all the SRM
    restrictions and guidelines.  If a Putter thread has no Getter threads,
    the mcc_event_put routine returned a CVR stating that no requests
    are outstanding.  If a Getter thread has no Putter threads it waits
    until a Putter thread puts something, then wakes up.  The model is
    similar to one-way pipes, but on a per-entity basis.  Although I may
    be oversimplifying the solution, it may be worth looking into.
    
    -Matt.

Yes this can be a pretty elegant solution. Though it can be seen as a 
"perverted" way to use the Event Manager.

One problem is that when we did our design no Event Manager was available,
another is that it is a bit too late for us (our product release was forecasted 
for the 1-FEB-1991 ...) and we are in qualification now.

What we really do in fact is sending mcc_calls and responses across mailboxes, 
and so we would need to have a bi-directional communication. But with a few 
threads on each side and some sensible schedule time for the mcc_event_get 
there should be no problem.

I hope this will give some ideas to less_advanced_in_their_development people.

Thanks and regards.

Pierre. 

    Just to remove the perversion :-)
    
    -Matt.

    
    From MCC, event_get and event_put are very useful for communicating.
    
    They have the added benefit of being platform independant.
    
    If DECmcc runs on the platform, then event_get and event_put work
    on the platform.
    
    In DECnet, we use event_get and event_put for the obvious purpose of
    getting DECnet events into DECmcc, but we also use these routines to
    allow any interactive DECmcc to communicate with the MCC_DNA4_EVL
    process on that system.  We use it for the disable handshake right now,
    but could use it for anything.
    
    It's not so perverse anyway.  Usually an event is defined as "any 
    significant occurrance".  From our perspective, having a user want
    something is pretty significant!
    
    -Jim