From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,b59b337045eece60
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!news.osn.de!diablo2.news.osn.de!news.belwue.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Structure of the multitasking server
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: 
 <8b4d1170-22e6-40d3-8ed1-096dc0163491@m36g2000hse.googlegroups.com>
  <ho90bg.gnt.ln@hunter.axlog.fr>
 <1w9y1ocmu2cm3$.724p6fohqdvy$.dlg@40tude.net>
 <259e95c5-92e6-4200-bc6e-5f35d99336a9@l64g2000hse.googlegroups.com>
Date: Sun, 21 Sep 2008 21:24:55 +0200
Message-ID: <11dyqk0lqb1je.ap31n7jjew7l.dlg@40tude.net>
NNTP-Posting-Date: 21 Sep 2008 21:24:57 CEST
NNTP-Posting-Host: dd5b64ab.newsspool1.arcor-online.net
X-Trace: 
 DXC=LMgkB]\cYCLj7E:bke<5HFic==]BZ:afN4Fo<]lROoRA<`=YMgDjhgB3mD`;8`@nHG[6LHn;2LCVN[<mhadbfdUKJDSL@n\j0=CdKOkk4LEgeL
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:2057
Date: 2008-09-21T21:24:57+02:00
List-Id: <comp.lang.ada>

On Sun, 21 Sep 2008 10:30:37 -0700 (PDT), Maciej Sobczak wrote:

> On 19 Wrz, 19:02, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> Note that task termination is usually a difficult problem in Ada. You
>> should pay an attention to this early.
> 
> No problem with that. With separate protected object (instead of
> rendezvous) it is enough to do this:

Of course there is a problem because conditional and timed entry calls may
not contain a "terminate" alternative. This is another reason why a
protected object might be a poor choice. But the way you used protected
object looks like a design noise. Technically you just replaced a
rendezvous queue with a protected entry queue. Instead of just server and
workers, you have server, workers, channels and management stuff. Very
OO-ish in the negative sense of this word.

The second problem which adds complexity is server to worker 1-n
communication. Should be n-1 worker to server, simpler (classic
client-server) and more efficient too.

Due to complexity you have overlooked to make a channel idle again after a
job is done. You also have overlooked to add a "Shut_Down" state in order
to finalize workers: four channel states instead of just none. And note,
that the type Channel cannot call to the procedure Finish to set Shut_Down
from its Finalize (if it were controlled). That is because Worker is a
component of. The thing will hang up on channel destruction. 

> There is no need to introduce any special type of job ("poison pill").

Job carries the parameters of a worker. You used it too, under the name
Job_Type.

> Above, the job space is not polluted with task lifetime management
> concepts - these should be kept separate.

You have polluted it with the procedure Finish, that has to be called
outside the worker tasks.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de