Re: Changes to records during asynch processing

[Benjamin Franksen <franksen@mail.bessy.de>]

Marty Kraimer wrote:
> 
> Benjamin Franksen wrote:
> 
> > P.S. I have the impression that nowadays asynchronous processing is
> > rather the rule than the exception, with the wide adoption of field
> > busses. Here at BESSY more than half the records with hardware device
> > support use CAN bus and so are asynchronous.
> 
> GTACS, the precurser of EPICS, did not have the concept of asynchronous records.
> Device support had to be written so that it was synchronous. Asyn support was
> invented for gpib devices. Once it was available people found many uses for it.
> Sigh!!

I am not so sure we should shed tears over asynchronous processing as
such. Surely it makes all the runtime support stuff a lot more
complicated. OTOH, the trend in the computer world is going more and
more towards asynchronicity, just look at all the network stuff. Latest
example are devices directly supporting VXI-11. You simply cannot do
these things synchronously and still keep the database running at a
reasonable speed.

I agree with Tim that we should aim at making the asynchronous
processing semantics follow the synchronous one as closely as possible
(within the limits of practicability).

In the long run I'd even suggest to re-think the database link semantics
for asynchronous target records. The Asynchronous Soft Support module I
wrote can be viewed as a little step in this direction.

I also agree with Jeff that the discussion is about enhancing the core
runtime system (making it more complex) in order to simplify the things
for the user (=database designer, developer of record and device
supports). I also agree that we have to be very careful about creating
overhead. The more radical changes that were proposed surely need a lot
of thinking, testing and optimizing.

Ben