| Alerting of intercepted routines:
Some system services are revectored to framework thread
synchronous routines in order to provide concurrency
of cpu work and i/o work, particularly those
system routines which might block the process for
an indefinite length of time.
For this reason the framework should perform special
work to assist in alerting threads which may
be blocked for an indefinitely long period of time,
eg sys$qiow read operation from a logical link or
a terminal input stream...
For a sys$qiow operation, the framework replacement routine
o issues a $qio operation
o blocks the thread until either an
ast fires or the thread receives an alert.
o if an alert is received, then the rtn
performs sys$cancel on the channel;
then waits until the i/o operation is completed
(VMS return either io$_abort or io$_cancel in iosb)
The client of the sys$qiow should check to see
whether or not an i/o (iosb) error of io$_cancel or io$_abort
was triggered by an alert by issuing a
mcc_thread_test_alert () function call.
For a rms get operation, I didn't know how to
cancel the current operation when the replacement
routine discovered that an alert was pending.
Consequently, the rtn just stays in the wait loop
until the i/o completes. For rms get on a terminal
input stream, fortunately rms its aborts the operation
so there is no problem. If one was doing transparent
decnet input via rms, then there would be a problem
for the thread would block indefinitely until the
input request was completed. I suppose that
the framework replacement routine could have
reached into the fab/rab and pulled out the
channel # and performed a cancel operation with it.
A quick scan of the
relevant source module found that sys$qiow is the ONLY
intercepted routine which performs special alert handling.
(Not to be fixed before v1.2)
The "main routine" thread is alertable like
any other thread. It has two special attributes:
(1) its stack is extensible (controlled by vms)
(2) when the main routine returns, then
the exit handlers and inner mode run-down routines are
run (so don't try to join with the main routine thread)
Your example is how the mcc main routine does the job.
For v1.1 the time interval will be a function of the number
of outstanding threads, rather than just a fixed time limit.
|
| RE .0
What you are proposing is almost exactly the algorythmn that is
used in the Notification FM. The only difference is that since the
NOTIFY request is always run in a seperate thread we don't really
care about waiting for only a specified period of time. We are more
concerned with if a thread returns back an error while attempting
to alert it, or if the join fails. when cleaning up remember you
need to recover that lost memory, if you simply exit the threads
without correctly terminating their operation you will not recover
any dynamically allocated memory that has not been freed.
|