| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 126.1 | Use MCC$TIME_CREATE to create your time parm | PETE::BURGESS | | Tue May 08 1990 13:56 | 11 |
| The error condition (%MCC-E-UNSUPP_OP, Unsupported operation)
resulted when MCC$TIMER_WAIT called MCC$TIME_IS_ABSOLUTE
with your "daytim" parameter. A more meaning error message
would be "Unsupported time data type" indicating that
your single parameter to the routine has a bogus descriptor/value.
MCC supports a extraordinary array of time formats.
Use MCC$TIME_CREATE, etc. to create your input parameter.
\Pete
|
| 126.2 | more questions about threads | TENERE::DUNON | Paul Dunon - Telecom Engineering - VBO | Wed May 09 1990 09:28 | 20 |
| OK, I had missed the point that MCC$TIME_CREATE ALLOCATES the MCC descriptor
and initializes it. Now it works.
The SRM doesn't mention that MCC$TIME_CREATE may return the set of error
condition values returned by MCC$TIME_IS_ABSOLUTE. This should be updated.
More questions:
1) When does a blocked thread (on MCC$TIMER_WAIT) become eligible for execution?
I assume when the time period elapses AND when rescheduling occurs (i.e. when
the user types a command at the MCC prompt). Right ?
2) When a thread resumes execution, what happens with the parameters passed
to the procedure at thread creation time ? Are they still valid ?
I don't think so because the call stack has been deallocated.
Thanks,
--Paul
|
| 126.3 | | GOSTE::CALLANDER | | Wed May 09 1990 16:31 | 5 |
| Note that the TRM is NON-BLOCKING, therefore you don't have to wait
on a user hitting the carriage return for something to get scheduled.
jill
|
| 126.4 | | PETE::BURGESS | | Fri May 11 1990 16:28 | 35 |
| >
> The SRM doesn't mention that MCC$TIME_CREATE may return the set of error
> condition values returned by MCC$TIME_IS_ABSOLUTE. This should be updated.
>
Don't you mean to say the MCC$TIME_WAIT may return the set of error...
condition values return by MCC$TIME* (create, is_absolute, delete,
compare, etc)
The SRM does try to say this on page 736.
>
> More questions:
>
> 1) When does a blocked thread (on MCC$TIMER_WAIT) become eligible for execution?
> I assume when the time period elapses AND when rescheduling occurs (i.e. when
> the user types a command at the MCC prompt). Right ?
>
When the condition (timer expires) becomes true,
then the thread becomes ready to run. When it receives
actually runs is an implementation secret- subject to random changes.
> 2) When a thread resumes execution, what happens with the parameters passed
> to the procedure at thread creation time ? Are they still valid ?
> I don't think so because the call stack has been deallocated.
>
The caller should pass parameters "by value"
eg address of parameter block
The thread-create routine creates the argument list
the stack of the created thread so these values are
persistent but certainly the "parent thread" stack
is volatile.
\Pete
|
| 126.5 | thanks | TENERE::DUNON | Paul Dunon - Telecom Engineering - VBO | Tue May 15 1990 06:52 | 16 |
| re .3
Yes, but when I run MCC with /DEBUG, my thread doesn't resume execution
after the timer expires, unless I type a command.
Could someone explain me why the debugger causes mcc scheduling not to
occur ?
re .4
Thanks for the info. My copy of the SRM is probably out-of-date, because
the page 376 is just saying that the routine may return the condition
values of MCC$TIME_CREATE ( and not MCC$TIME* ).
-- Paul
|
| 126.6 | /debug restricted | PETE::BURGESS | | Tue May 15 1990 12:36 | 9 |
| I think that the release notes point out the restriction that system service interception
is not currently done when the debugger or pca is activated. The reason for this
is the both pca and the debugger perform interception as well and the
two methods don't cooperate with each other. I am investigating whether
MCC can share their method.
Let me know if your timers don't fire during /nodebug operation.
\Pete
|