From: "Björn Lundin" <b.f.lundin@gmail.com>
Subject: Re: GNAT and Tasklets
Date: Fri, 19 Dec 2014 12:56:56 +0100
Date: 2014-12-19T12:56:56+01:00 [thread overview]
Message-ID: <m713pl$l7a$1@dont-email.me> (raw)
In-Reply-To: <m6vmbu$82q$1@loke.gir.dk>
On 2014-12-19 00:01, Randy Brukardt wrote:
> For something like sockets, which are relatively slow compared to the
> computer, polling has no visible effect on performance and ensures that
> nothing will get starved.
>
> If you're using a high-level communication library (not some low-level
> sockets bindings - yuck!), how that's implemented is invisible to the
> client. They shouldn't care.
Well, it is the yuck alternative.
A homebrew binding from 1996 with far to much
exposed in the spec, making change difficult.
To much backwards incompability.
It resembles a bad version of AdaSockets.
>>
>> 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)
>
> That sounds confused to me. One would expect a communication abstraction
> that all the business logic calls as needed.
No. you want to separate the business logic from the actual protocol.
You do it with libraries, but this design uses a set of specialized
processes with IPC via names pipes. So the I/O process gets commands
from business process. the I/O process then converts these commands
to the actual protocall, and is responisible for securing data until acked.
By this design, just change the I/O is fairly easy and maintainable
business-process <-IPC-> I/O <-whatever proto-> PLC
The internal IPC proctocol does not change.
The busines process does not care about socket/serial/usb/
its the isolated I/O process' responsibility
Change I/O process, and you are done with protocol-to-plc upgrade
>How that abstraction is
> organized should not be visible to the business logic at all.
and it is not as per above
> But we're getting way off-topic here, you're not going to redesign your
> application because I think it sounds confused
correct, let's leave it here.
> I still think this sounds way too low-level.
I/O in our industry _is_ low-level.
> But I hope you're using a nice Ada abstraction of sockets and not
> just calling raw C routines to do stuff. (If you are, you're hopeless and
> this whole discussion is irrelevant.)
So, just let us call me hopeless.
However, I do know about Murphy's law
"if it _can_ happen it _will_ happen"
This design runs at site with 50_000 + tote movements per day, and has
for many years. A tote move will need say 10 messages back-and forth
in cranes and conveyors for going out from store and back in again.
This gives about half a million messages - a day - on a busy site.
Murphy should have kicked in here long time ago.
This design do work very well.
> Right. And even on the systems where it worked, you're dependent that your
> sockets library doesn't do any buffering (NC_Sockets can), doesn't have any
> local data other than a sockets handle, and the like. A updated sockets
> library might change that behavior.
correct, but homebrew (yuck) also means full control. No buffering.
--
Björn
next prev parent reply other threads:[~2014-12-19 11:56 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 16:31 GNAT and Tasklets vincent.diemunsch
2014-12-11 10:02 ` Jacob Sparre Andersen
2014-12-11 16:30 ` Anh Vo
2014-12-11 18:15 ` David Botton
2014-12-11 21:45 ` Egil H H
2014-12-11 23:09 ` Randy Brukardt
2014-12-12 2:28 ` Jacob Sparre Andersen
2014-12-12 8:46 ` vincent.diemunsch
2014-12-12 23:33 ` Georg Bauhaus
2014-12-13 2:06 ` Brad Moore
2014-12-13 6:50 ` Dirk Craeynest
2014-12-14 0:18 ` Hubert
2014-12-14 21:29 ` vincent.diemunsch
2014-12-16 5:09 ` Brad Moore
2014-12-17 13:24 ` vincent.diemunsch
2014-12-16 4:42 ` Brad Moore
2014-12-17 13:06 ` vincent.diemunsch
2014-12-17 20:31 ` Niklas Holsti
2014-12-17 22:08 ` Randy Brukardt
2014-12-17 22:52 ` Björn Lundin
2014-12-17 23:58 ` Randy Brukardt
2014-12-18 10:39 ` Björn Lundin
2014-12-18 23:01 ` Randy Brukardt
2014-12-19 8:39 ` Natasha Kerensikova
2014-12-19 23:39 ` Randy Brukardt
2014-12-19 8:59 ` Dmitry A. Kazakov
2014-12-19 11:56 ` Björn Lundin [this message]
2014-12-20 0:02 ` Randy Brukardt
2014-12-18 8:42 ` Dmitry A. Kazakov
2014-12-18 8:56 ` vincent.diemunsch
2014-12-18 9:36 ` Dmitry A. Kazakov
2014-12-18 10:32 ` vincent.diemunsch
2014-12-18 11:19 ` Dmitry A. Kazakov
2014-12-18 12:09 ` vincent.diemunsch
2014-12-18 13:07 ` Dmitry A. Kazakov
2014-12-19 10:40 ` Georg Bauhaus
2014-12-19 11:01 ` Dmitry A. Kazakov
2014-12-19 16:42 ` Brad Moore
2014-12-19 17:28 ` Dmitry A. Kazakov
2014-12-19 18:35 ` Brad Moore
2014-12-19 20:37 ` Dmitry A. Kazakov
2014-12-20 1:05 ` Randy Brukardt
2014-12-20 17:36 ` Brad Moore
2014-12-21 18:23 ` Brad Moore
2014-12-21 19:21 ` Shark8
2014-12-21 19:45 ` Brad Moore
2014-12-21 23:21 ` Shark8
2014-12-22 16:53 ` Brad Moore
2014-12-21 21:35 ` tmoran
2014-12-21 22:50 ` Brad Moore
2014-12-21 23:34 ` Shark8
2014-12-22 16:55 ` Brad Moore
2014-12-22 23:06 ` Randy Brukardt
2014-12-20 16:49 ` Dennis Lee Bieber
2014-12-20 17:58 ` Brad Moore
2014-12-19 19:43 ` Peter Chapin
2014-12-19 20:45 ` Georg Bauhaus
2014-12-19 20:56 ` Dmitry A. Kazakov
2014-12-19 23:55 ` Randy Brukardt
2014-12-19 23:51 ` Randy Brukardt
2014-12-18 22:33 ` Randy Brukardt
2014-12-19 13:01 ` GNAT�and Tasklets vincent.diemunsch
2014-12-19 17:46 ` GNAT?and Tasklets Brad Moore
2014-12-20 0:39 ` GNAT and Tasklets Peter Chapin
2014-12-20 9:03 ` Dmitry A. Kazakov
2014-12-20 0:58 ` GNAT�and Tasklets Randy Brukardt
2014-12-18 9:34 ` GNAT and Tasklets Niklas Holsti
2014-12-18 9:50 ` Dmitry A. Kazakov
2014-12-17 21:08 ` Brad Moore
2014-12-18 8:47 ` vincent.diemunsch
2014-12-18 21:58 ` Randy Brukardt
2014-12-17 22:18 ` Randy Brukardt
2014-12-18 0:56 ` Shark8
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox