Experimental Physics and
Industrial Control System

Eric Norum <[email protected]> · Tue, 22 Feb 2011 13:08:33 -0800

In response to the interest shown in this I've asked Andrew to put the asynOctet IOCSH device support onto the EPICS module support page.
It provides a somewhat safer mechanism for running commands as the result of record processing in that it runs the command in a thread separate from the record processing thread.

There may very well be race conditions introduced by running IOCSH commands in a context other than that of the interactive command sessions -- Caveat Emptor.

> 
> Andrew Johnson wrote:
>> On Monday 21 February 2011 11:59:42 Ralph Lange wrote:
>>> On 21.02.2011 18:45 Eric Norum wrote:
>>>> I wrote a simple asynOctet driver to do this.  I've not yet packaged this
>>>> up for official release until I hear back from the folks testing this.
>>>> I'm not 100% sure that it's a good idea to allow commands to be run as
>>>> the result of record processing, but maybe there's a real need out there.
>>> Any subroutine record can execute commands in the context of record
>>> processing. Where's the big difference?
>> I think the word "command" implies the distinction.  Many of the older IOC test and debugging commands were coded with the assumption that they would be run from the vxWorks shell, i.e. they're running in a very high priority thread and won't normally be preempted by record processing, so they maybe don't do as much locking as they should (indeed there may even be locks missing from dbBase that would be needed to make them completely reliable and thread-safe when used in that way, but adding such locks could adversely affect the performance of the IOC).
>> I suspect that the 'dbl' command should be safe to run from record processing since we don't support the ability to add or delete records at run-time, but commands like 'scanppl' or 'dbior' might have subtle interactions that could cause deadlocks, crashes or just wrong results in some circustances.  I haven't examined any source code in writing this response so I could be wrong about my specific examples, but if anyone is going to rely on the ability to run these kinds of commands from record processing they should do their own due diligence about them first.
>> There's also the issue of blocking which Eric just brought up; if the command takes a long time to run it could prevent other real-time operations from operating normally.
>> - Andrew
> 

-- 
Eric Norum
[email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System