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,eb0daafec4ae827a X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!v3g2000hsg.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: High-integrity networking Date: Mon, 08 Oct 2007 13:35:49 -0700 Organization: http://groups.google.com Message-ID: <1191875749.647965.104600@v3g2000hsg.googlegroups.com> References: <1191845623.383675.190820@d55g2000hsg.googlegroups.com> <20071008175356.W2321@docenti.ing.unipi.it> NNTP-Posting-Host: 85.3.224.139 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1191875749 3732 127.0.0.1 (8 Oct 2007 20:35:49 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 8 Oct 2007 20:35:49 +0000 (UTC) In-Reply-To: <20071008175356.W2321@docenti.ing.unipi.it> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: v3g2000hsg.googlegroups.com; posting-host=85.3.224.139; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news2.google.com comp.lang.ada:2358 Date: 2007-10-08T13:35:49-07:00 List-Id: On 8 Pa , 18:03, Colin Paul Gloster wrote: > |----------------------------------------------------------------------| > |"Ravenscar describes the language subset and the usage patterns for | > |multitasking within a single process." | > |----------------------------------------------------------------------| > > RAVENSCAR is not about patterns. I do not believe that even Tullio > Vardanega claimed that in his paper "Ravenscar design patterns?: > reflections on use of the Ravenscar profile". I didn't mean "design patterns", but "usage patterns" in the sense that some things are discouraged/forbidden and some others are promoted/enforced. > A RAVENSCAR task is a process. Multiple threads inside one process are > not possible in RAVENSCAR. Could you please throw some references? A relevant citation from the Ravescar document itself would be perfect. I have found *one* paragraph indicating that tasks are single-threaded and *many* paragraphs about shared variables, global data, and so on. As far as I'm concerned it does not really matter how the program is deployed on the given system - and if it's deployed on bare metal (no OS underneath), then the distinction between processes and threads does not make any sense anyway. The only thing I find important is that the complete Ravenscar program, comprising potentially many tasks, is a *single entity* from the deployment point of view - whatever that means on the given target platform. But I'm not asking about Ravenscar. > |----------------------------------------------------------------------| > |"I'm interested in patterns and solutions for high-reliability | > |networking/middleware. | > | | > |Just "extrapolating" Ravenscar to the distributed environment can lead| > |to some imaginably constrained environment where [..] | > |[..], the types (and lengths) of messages are | > |known up front, etc. | > |There are some start-up issues with ensuring all these constraints | > |(for example, the locations of other nodes would need to be first read| > |from some configuration file/database before the connections can be | > |established, etc., [..] | > | | > |[..]" | > |----------------------------------------------------------------------| > > RAVENSCAR is not intrinsically specific to the packet-switching > paradigm. I'm not asking about Ravenscar. I'm asking about recommended reading in the area of high-integrity networking and middleware. I have mentioned Ravenscar to give you a hint on what is the kind of document that could be the closest analogy to what I'm looking for. Any recommendations? -- Maciej Sobczak * www.msobczak.com * www.inspirel.com