Re: Private or public task ?

["Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr>]

On 5 fév, 22:40, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> This is illegal, because protected procedure shall not perform potentially
> blocking actions (like I/O.
As Jeffrey pointed out as well. I will check the RM about it (I have
to establish I've missed it).

> You do not need to worry about that. Unless you are using pointers, the
> task object's scope encloses any calls to its entries. Therefore it simply
> cannot terminate due to its finalization before any entry call.

**it simply cannot terminate due to its finalization before any entry
call**

That's clever to notice ! OK, I see. Now I understand Jeffrey's
doubts.

> If you want garbage collection because of pointers involved then just do
> it. Don't break the task interface, make a handle type pointing to the task
> object. When the last handle vanishes, deallocate the task. That is.
“ Deallocate the task ” ? If I want to deallocate, I have to request
it to completes, and for the latter, I need it to have a corresponding
request entry... which would need to be public (as private entry
accessible from implementation is not possible).

> Task component does not work in most real-life cases.
My words was wrong : I was not to talk about using task as record
components, I was to say task may be implementation details, just like
record components are.

> Yes, an entry call can be syntactically and semantically different than a
> call to a procedure.
Syntactically : can be wrapped in a procedure call.
Semantically : sure if protected objects are required to not invoke
blocking operations, this is semantically different.

> You can print from the rendezvous. That is not a problem. Some tight
> implementations would prefer buffering in the rendezvous in order to
> release the caller as soon as possible (minimizing the effect of priority
> inversion). I.e. Text is first copied into the task's buffer during the
> rendezvous and printed later outside the rendezvous before accepting the
> new one. Assuming that the callers run at a higher priority and do not
> print very often leaving the processor free most of the time, this would
> give better response times in the callers (at the cost of some overall
> performance hit).
I like this hint (have a taste of real-time design by the way).