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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.51.228 with SMTP id n4mr12984910obo.28.1403596353865; Tue, 24 Jun 2014 00:52:33 -0700 (PDT) X-Received: by 10.140.94.182 with SMTP id g51mr5154qge.17.1403596353774; Tue, 24 Jun 2014 00:52:33 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!news.glorb.com!hn18no8315567igb.0!news-out.google.com!a8ni10889qaq.1!nntp.google.com!i13no10918129qae.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 24 Jun 2014 00:52:33 -0700 (PDT) In-Reply-To: <5156oy7vhg99.17wu6q2ef45ke.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=195.182.34.254; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S NNTP-Posting-Host: 195.182.34.254 References: <1402308235.2520.153.camel@pascal.home.net> <85ioo9yukk.fsf@stephe-leake.org> <255b51cd-b23f-4413-805a-9fea3c70d8b2@googlegroups.com> <5ebe316d-cd84-40fb-a983-9f953f205fef@googlegroups.com> <2100734262424129975.133931laguest-archeia.com@nntp.aioe.org> <5156oy7vhg99.17wu6q2ef45ke.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <1d3612ad-f85a-489c-b4bc-0c23d5d67de3@googlegroups.com> Subject: Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! From: Maciej Sobczak Injection-Date: Tue, 24 Jun 2014 07:52:33 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:20576 Date: 2014-06-24T00:52:33-07:00 List-Id: > When implementing > stuff like network communication (e.g. HTTP servers) and parallel > processing we frequently have a set of state machines (one per connection= ) > too expensive to handle from OS tasks. Right. > Programming a state machine is > turning all design upside down. Or not, depending on how the connection (and its state) is perceived in the= whole system. If you want your connections to have a life that is independ= ent on other connections (that might be a valid idea in a non-critical HTTP= server), then it might be useful to express that independence at a code le= vel, with a code that seems to be confined to a single task of handling tha= t single connection. But if you want a connection handling that manages the= system as a whole (traffic shaping based on the overall performance is an = example obvious reason for this), then state machines seem to be spot-on. Also, the communication paradigm influences whether this is a problem or no= t - in messaging systems, where message is a unit of transfer and processin= g, this is not a problem at all. HTTP servers can be treated in the same wa= y, as they are not stream-oriented, but request-oriented. > If there were user-defined task support one > could program this as if it were in proper tasks. Maybe not "proper tasks", but something similar that has an explicit interf= ace to "push" its execution forward up to the next "switching point", so th= at the application can decide on its own when that "pushing" should take pl= ace. The difference is that normal tasks are propelled by the run-time (for exam= ple by the OS-level thread) and the application has no influence on this, w= hereas what is needed here is the task-like language feature that can be pr= opelled at the discretion of the application. Now that could be useful, but= this explicit interface for pushing the task forward is what would make it= distinct from "proper tasks". --=20 Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com