Re: Private or public task ?

["Alex R. Mosteo" <alejandro@mosteo.com>]

Hibou57 (Yannick Duchêne) wrote:

> Hi Jeffrey, nice to meet you again,
> 
> On 5 fév, 22:38, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
> wrote:
>> Technically this is a bounded error: Ada.Text_IO.Put* operations are
>> potentially blocking, and should not be called from a protected
>> operation.
> I did not ever suspected such a requirement. Transitive blocking is
> not allowed ?
> 
> So, if blocking operation are not allowed from a protected type,
> clients of a given operation have to know it weither or not it's
> potentially blocking, and so, this fact must be stated in public part
> of specifications, so then, the protected and tasked aspect of a
> method must be stated in specifications and I suppose it's not a good
> idea to make it private.

I have had some headaches not long along because of potentially blocking 
operations. The short conclusion is that as long as you don't try anything 
strange, you'll do well. By strange I mean things that may seem "clever" at 
some point like calling a task from a protected or so.

Past versions of gnat where indulging about this, there's now a pragma that 
won't allow it and that I recommend to use; you'll save further problems 
with deadlocks. I think is pragma Detect_Blocking.

So, if your type is encapsulating a hidden call to a task entry, it would be 
advisable to document it in the call, because this indeed can raise an 
exception at runtime if called from a protected op. I think this is a 
recommendation, but a bounded error in any case. The above pragma enforces 
its detection.

However, I don't think it's recommended design to call from protected ops to 
foreign, implementation-unknown, subprograms. Protected calls should 
encapsulate something as well defined and narrow as possible.

I make extensive use of protected and task types generally without issue; my 
problem was that I had to quickly hack a solution for a convoluted tasking 
subsystem and I was frankly abusing the design. In general, sticking to the 
client-server model for tasks/protected objects covers 99% of use cases and 
it's totally safe.

> Wrong or right assumptions ?
> 
>> This should not happen. Did you actually experience this?
> No, I did not experience it, this was just my imagination : I knew a
> task may completes at its own discretion. Thus if may possibly
> completes too much soon if its completion condition is not well
> designed.
> 
> I will have to check the RM, but I'm pretty sure a completed task
> cannot handle any request any more (at least, this seems to be a
> reasonable assumption to me, but I will still have to check...).

At first I also was reticent of terminate parts, but this is really one of 
these nice aspects of Ada where something apparently complex is done for you 
by the language :)