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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: =?UTF-8?B?QmrDtnJuIEx1bmRpbg==?= Newsgroups: comp.lang.ada Subject: Re: =?UTF-8?B?R05BVMKgYW5kIFRhc2tsZXRz?= Date: Thu, 18 Dec 2014 11:39:44 +0100 Organization: A noiseless patient Spider Message-ID: References: <455d0987-734a-4505-bb39-37bfd1a2cc6b@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Thu, 18 Dec 2014 10:39:26 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="81445ba98bc62adc89039fc6b141d8cb"; logging-data="1905"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19TssyJ9xbnlfjm+QEfXBWF" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 In-Reply-To: Cancel-Lock: sha1:GzRBpez0XxnD6xlfd/kUGuVb0X0= Xref: news.eternal-september.org comp.lang.ada:24109 Date: 2014-12-18T11:39:44+01:00 List-Id: On 2014-12-18 00:58, Randy Brukardt wrote: >> That kind of rules out a common pattern we have in communication >> processes. > > Certainly not: my web and mail servers do plenty of communication! Sorry. should have been more clear. I meant a common pattern we have at work. >> Usually we set up a socket, globally, in a package body. >> >> One task does a blocking select() - thus hanging on it - for say 5-30 s. > > Here's the problem, you're thinking at much too low of a level. The Claw/NC > sockets libraries abstract sockets comminucation into an I/O model (no such > thing as "select"!). And the implementation can avoid actual blocking (even > though at the call level you will see what appears to be blocking). > > Get (My_Socket, Timeout => 30.0, Item => Buffer, Last > => Last); > > This will appear to block for 30 seconds, but it surely doesn't have to be > *implemented* that way. But then you get to poll, no? well that will do it of course. > > I don't see any sense to the other tasks that you have (I realize I don't > understand the precise problem that you are trying to solve). But it all > seems WAY too low-level to me; Not really Task 1 is for just receiving data,secure it, and notify others. Task 2 is to serialize _writes_ to the socket. PO's cant be involved in potentially blocking stuff. Tasks 3 is a to have keepAlive telegrams. KeepAlives are usually mandatory at protocol level, so in order not to jam that logic into the the writer task, it is taken out into a separate one. Easier to maintain. The shutdown things and select() is just to be able to send a message (on a named pipe) that the process is to go down and thus the tasks must shut down. They will not if blocking on read() >the reason for using such a pattern is that > you need high speed responsiveness (far faster than human speeds) -- No. The reason is to have communication logic for say a crane or conveyor system in one process, and the business logic for that mechanical device in another process. (I'm talking about a warehouse control system here, with 20-50 daemon processes) Having several I/O-processes makes it easy to change the way of communication, and still have the same business logic. (say an installation from 1992 talks Siemens 3964r/k512 over a serial line (its a old standard protocol) and they want to switch plc's which talks tcp/ip with another transmission protocol. If keeping the messages within the protocol intact, then it's just matter of a new I/O process. The rest of the system is untouched including business logic processes. (I just did this this spring) > otherwise sticking with a simple I/O model is much easier to understand for > maintenance. Yes, but it also has to work. > > On top of which, using the same (Ada) object from two different tasks > without synchronization is an invalid use of shared variables. Such a > program is technically erroneous, and as such, it could do anything at all. Hmm, is it? I got this from stackoverflow. "You don't have to worry about it. One thread reading and one thread writing will work as you expect. Sockets are full duplex, so you can read while you write and vice-versa. You'd have to worry if you had multiple writers, but this is not the case." And that is basically what I heard before. So it does work, and works well. But of course, it may be illegal anyway. > So I'm dubious that your pattern even works on other compilers (regardless > of the blocking issue). It did work well with ObjectAda too, but that was 10 years ago. AlsysAda for AIX did not like this. It had, as Janus has, tasking in its runtime, and anything blocking would block all. > It's unfortunate that Ada doesn't have any static > checking for such things, because it's all too easy to write something that > works today but won't work in the future. > Yes, This makes me think that access to it should be wrapped in a PO -- Björn