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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM 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!postnews.google.com!m73g2000hsh.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Structure of the multitasking server Date: Tue, 23 Sep 2008 01:07:38 -0700 (PDT) Organization: http://groups.google.com Message-ID: <87ea7e07-1163-4fe5-8162-c5d46eed5bf7@m73g2000hsh.googlegroups.com> References: <8b4d1170-22e6-40d3-8ed1-096dc0163491@m36g2000hse.googlegroups.com> <1w9y1ocmu2cm3$.724p6fohqdvy$.dlg@40tude.net> <259e95c5-92e6-4200-bc6e-5f35d99336a9@l64g2000hse.googlegroups.com> <11dyqk0lqb1je.ap31n7jjew7l.dlg@40tude.net> <1ey0wvc4tun7g$.15u4xyef05055$.dlg@40tude.net> <29fcd27f-aefd-4787-b8f6-5f8a04bd0f42@z72g2000hsb.googlegroups.com> <1njy6zbrm8yv0.fmtwebrb08bq$.dlg@40tude.net> NNTP-Posting-Host: 128.141.45.232 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1222157259 17763 127.0.0.1 (23 Sep 2008 08:07:39 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 23 Sep 2008 08:07:39 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: m73g2000hsh.googlegroups.com; posting-host=128.141.45.232; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:2068 Date: 2008-09-23T01:07:38-07:00 List-Id: On 22 Wrz, 16:11, "Dmitry A. Kazakov" wrote: > >> There also exists a third variant with an > >> exception propagation. > > > This assumes rendezvous. > > Nope. > Here is my example with exceptions (a complete program): [...] This example uses rendezvous. I don't like it, because it misuses exceptions for something that is a perfectly normal control flow. Yes, this is very subjective - for the record, I also don't like the End_Error exception. BTW - the fact that you raise an exception only to shut it up in the same scope indicates that this is a severe misuse of some language feature. > > In the version with protected objects the entity that triggers > > termination might be different from the one that invents job. > > In your version these different responsibilities are mixed. > > It does not work. You cannot selectively call to multiple entries of a > protected object anyway. I don't have to. What I said is that the entities that provide jobs and that trigger termination can be different, not that the worker can get them from separate channels. > Then again, termination should be triggered by > task finalization Why? Which task? The termination of workers can be triggered by the load that is below some threshold. This is a valid strategy for dynamic task pool and is not necessarily related to the finalization of the main task. > > In particular, in my version the task that > > invents jobs is never blocked on interactions with workers. This is a > > big advantage, because such a blocking would disturb its own > > interactions with the environment and reduce its responsiveness. > > This is a design fault. Under certain conditions it must either block or > fail. Where is the design fault? The immediate failure (as opposed to blocking) can be a valid overload handling policy. If I go to some office and cannot be handled because of the clerks being too busy, I prefer to know it *immediately*, so that I can go to the pub. > > In your version with rendezvous the task that invents jobs has to > > block and during that time it cannot react to the events that drive it > > (keyboard input, network transmission, etc.). > > Wrong, see 9.7.1(16). Again: keyboard input, network transmission, etc. Select statement is not flexible enough. In addition, there is no need to create even more tasks only to fit to select's limitations. > Your design is when a multicasting > publisher "knows" its peers. This is a bad idea, obviously. Why it is a bad idea? What is bad in the manager having knowledge about workers in his team? Is your boss aware of you or do you need to constantly ask him for new tasks? BTW - there is no multicasting in my design. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com Database Access Library for Ada: www.inspirel.com/soci-ada