Re: Ada.Text_IO and protected objects

["fabio de francesco" <fmdf@tiscali.it>]

Jacob Sparre Andersen wrote:
> Fabio de Francesco wrote:
>
> > Thank all of you. I have thought a while about the need to start a
> > third task to do the actual writing to Standard_Output as the
second
> > variant mentions. I decided not to do it because the original
> > problem is to manage two different printer devices or output files,
> > one at each door.
>
> If you write to two _different_ files in the two different tasks,
then
> you're safe, but that was not what you were doing.

Yes, indeed.

>
> > Otherwise there wouldn't be any need two have two different tasks
to
> > emit tickets, only one would suffice. (I hope I am not missing
> > something...)
>
> What the two tasks in youre examle are doing, is: logging that the
> protected object issues tickets to them - to a _common_ log.

You're correct: to a common log. That was only a test to acquaint
myself with tasks and protected types. My attention was to the
protected object behaviour and to the general structure of a program
with tasks.

Initially the program was raising contrained errors and many of you
helped to find the bugs in it. Those errors weren't related at all to
output, in fact now it works for doing what it has been designed.

At first I wasn't particularly interested to the output, that is it
doesn't mattered to get output lines ordered by increasing "ticket"
numbers. I was only interested at solving the immediate issue that
couldn't make the program run.

Only after someone explained that output could get out interleaved I
became to investigate this other issue. So in my latest post I asked
how you would do if it were needed that lines didn't get interleaved
when going to the same output channel. Just to know how to do it when
it is required.

> > Anyway just to reason on the solution Dmitry and Jacob suggest, how
> > would you implement that one? If I have understood there would be
> > the need for a third task in charge to handle IO. I suppose it
means
> > that the other two tasks have to emit "tickets" to a protected
queue
> > that would be later read by the third task in order to print
> > them. Is it what you mean? How can we assure that all elements in
> > queue are ordered by increasing numbers if any of the previous two
> > tasks add tickets to this queue at random times? I think there must
> > be something I didn't catch. I am not even sure you were proposing
a
> > queue working in terms I explained here. Can you make your solution
> > clearer for me, please?
>
> Your original specification (if one can say there was any) didn't say
> anything about having to log the issued tickets in sequence.  Please
> give us a more exact description of what you want to do, before we
> start making speculative experiments based on more or less wild
> guesses.

Yes, indeed. I hope I've made it clearer. That's it. Sorry for my
English.

Regards,

fabio de francesco