tk_rpl_rdv
Reply Rendezvous
ER ercd = tk_rpl_rdv ( RNO rdvno, VP msg, INT rmsgsz ) ;
RNO rdvno Rendezvous number
VP msg Reply message packet address
INT rmsgsz Reply message size (in bytes)
ER ercd Error code
E_OK Normal completion
E_PAR Parameter error (rmsgsz < 0, rmsgsz > maxrmsz, or value that cannot be used in msg)
E_OBJ Invalid object state (rdvno is invalid)
E_CTX Context error (issued from task-independent portion (implementation-dependent error))
Returns a reply to the calling task in the rendezvous, ending the rendezvous.
The task issuing this system call (here “Task X”) must be engaged in a rendezvous; that is, this system call can be issued only after executing tk_acp_por. In the discussion that follows, the rendezvous calling task is “Task Y”, and the rendezvous number passed in a return parameter by tk_acp_por is rdvno. When tk_rpl_rdv is executed in this situation, the rendezvous state between Task X and Task Y is released, and the Task Y state goes from WAIT for rendezvous completion back to READY state. When a rendezvous is ended by tk_rpl_rdv, accepting Task X can send a reply message to calling Task Y. The contents of the message specified by the accepting task are copied to the memory space specified in msg passed by Task Y to tk_cal_por. The size of the reply message rmsgsz is passed as a tk_cal_por return parameter.
Error code E_PAR is returned if rmsgsz is larger than maxrmsz specified with tk_cre_por. When this error is detected, the rendezvous is not ended and the task that called tk_cal_por remains in WAIT state for rendezvous completion.
It is not necessary to issue tk_fwd_por and tk_rpl_rdv from a task-independent portion, but it is possible to issue these system calls from dispatch disabled or interrupts disabled state. This capability can be used to perform processing that is insE_PARable from tk_fwd_por or tk_rpl_rdv. Whether or not error checking is made for issuing of these system calls from a task-independent portion is implementation-dependent.
If a task calling a rendezvous aborts for some reason before completion of the rendezvous (before tk_rpl_rdv is executed), the accepting task has no direct way of knowing of the abort. In such a case, error code E_OBJ is returned to the rendezvous accepting task when it executes tk_rpl_rdv.
After a rendezvous is established, tasks are in principle detached from the rendezvous port and have no need to reference information about each other. However, since the value of maxrmsz, used when checking the length of the reply message sent using tk_rpl_rdv, is dependent on the rendezvous port, the task in rendezvous must record this information somewhere. One possible implementation would be to put this information in the TCB of the calling task after it goes to WAIT state, or in another area that can be referenced from the TCB, such as a stack area.
The parameter rdvno is passed to tk_rpl_rdv and tk_fwd_por as information for distinguishing one established rendezvous from another, but the rendezvous port ID (porid) used when establishing a rendezvous is not specified. This is based on the design principle that tasks are no longer related to rendezvous ports after a rendezvous has been established.
Error code E_OBJ rather than E_PAR is returned for an invalid rdvno. This is because rdvno itself is an object indicating the task that called the rendezvous.
Comments