Experimental Physics and Industrial Control System
|
StreamDevice executes shell commands in the context of one of the three
standard callback threads, depending on the PRIO field of the record.
Originally I had implemented this feature to be able to change the
serial parameters of an asyn port if necessary. Of course nothing stops
anyone to call "dbl>file" or "casr 3" wich may take a long time to
execute, or even "iocPause.
It is always possible to do bad things during record processing, e.g. in
a subroutine record as Ralph pointed out. The same is true for SNL code.
No API is "fool proof". This is just another point in EPICS where "you
should know what you are doing".
Dirk
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 simply 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
- Replies:
- Re: [Fwd: Re: stream without asynPort] Eric Norum
- References:
- [Fwd: Re: stream without asynPort] Dirk Zimoch
- Re: [Fwd: Re: stream without asynPort] Eric Norum
- Re: [Fwd: Re: stream without asynPort] Ralph Lange
- Re: [Fwd: Re: stream without asynPort] Andrew Johnson
- Navigate by Date:
- Prev:
Re: [Fwd: Re: stream without asynPort] Andrew Johnson
- Next:
ITER CODAC Core System Vs 2.0 released Di Maio Franck
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: [Fwd: Re: stream without asynPort] Andrew Johnson
- Next:
Re: [Fwd: Re: stream without asynPort] Eric Norum
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 18 Nov 2013 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|