| >
> 1. I have an FM running in a thread and it makes a call to an AM
> using mcc_call_access. If I send an alert to the FM thread to
> terminate it while the AM is actually running, will mcc_call_access
> return MCC_S_ALERT_TERMREQ? Is it up to the AM to catch the alert and
> return the MCC_S_ALERT_TERMREQ status code?
>
On VMS the thread pc moves to back and forth between the FM and AM
modules, so whatever code receives an MCC_S_ALERT_TERMREQ cvr
is responsible for servicing the condition.
On ULTRIX the "logical thread" is distributed between two
servers: FM thread and the AM thread. When the FM thread
invokes an AM service, then the FM thread is blocked, waiting
for the completion of MCC_CALL_ACCESS.
The control flow varies a bit depending on whether the mcc_call
is "single-reponse" or a "multiple-response" type.
If the FM thread sent an alert while waiting for IPC response from the AM,
then the alert will be delivered to the IPC code, which will send an
IPC control message to the AM server "alert service thread" to
send an alert to the AM thread. When the AM thread returns from its
service routine and its reponse/exception parameters are returned to the
calling module(FM); then the handle is checked- when the AM handle
was returning "more", then the IPC server stub cancels the handle
and calls the AM service again to do its requested cleanup.
If the FM was executing FM code (ie your FM code), then it is expected
to cancel any outstanding multiple-reponse handles and calls so that
resources are cleaned up.
> 2. If I defer alerts before calling mcc_thread_create2 to create a
> thread for an FM call, are alerts deferred in the FM thread? I'm
> wondering if all threads start out with alerts enabled or is the alert
> deferred state transferred across the thread create call?
>
The alert defer/restore calls operate on the CURRENT THREAD only.
When a thread is created, then alerts are enabled.
> 3. Finally, similar to question 2. If I defer alerts and then call
> mcc_thread_send_alert, will the alert be delivered? I assume the
> defer alert call is only for the current thread.
>
"If I defer alerts" - this operation would only effect delivering
an alert to the current thread.
In the SRM sections 12.1.14 and 12.2.1 describe the data flow
for cancelling multiple reponse calls and aborting threads.
While the underlying mechanisms have changed to support the ULTRIX
execution model, the MM interfaces and semantics have been preserved
for v1.*
|
| Is it safe to allow alerts to interrupt mcc_thread_join_any? I assume
that by checking the value of the parameter which receives the id of a
terminated thread, I will be able to tell if a thread actually joined
the current thread. That is, if it is possible to have a thread join
and still have mcc_thread_join_any return MCC_S_ALERT_TERMREQ? Or is
there a point within the join_any call after which an alert may not be
delivered so that if ALERT_TERMREQ is returned, then by definition, the
join operation could not have happened.
John
|
| >
> Is it safe to allow alerts to interrupt mcc_thread_join_any?
One requirement for all the framework routines was
to provide certainty about the result of the common rtn
if interrupted by an alert. The model is the if the fw
rtn returns with MCC_S_ALERT_REQ, then the OPERATION did
not START or the OPERATION was ROLLED BACK to the initial condition.
QIOW etc. sometimes breaks this model, eg
if pending-alert, then return return (...)
qio
wait for completion or alert
if alerted, then sys$cancel and wait for completion and wish
that there was a way to undo the i/o request !!!!
I did my best to convince everyone else to follow this model
where it was appropiate to undo transaction/operation side-effects.
> I assume
> that by checking the value of the parameter which receives the id of a
> terminated thread, I will be able to tell if a thread actually joined
> the current thread. That is, if it is possible to have a thread join
> and still have mcc_thread_join_any return MCC_S_ALERT_TERMREQ? Or is
> there a point within the join_any call after which an alert may not be
> delivered so that if ALERT_TERMREQ is returned, then by definition, the
> join operation could not have happened.
>
If the rtn returns with mcc_s_alert_termreq, then the join did not occur
if the rtn returns with mcc_s_normal, then the alert was not delivered.
\Pete
|