EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: [Fwd: Re: stream without asynPort]
From: Andrew Johnson <[email protected]>
To: [email protected]
Cc: Eric Norum <[email protected]>
Date: Mon, 21 Feb 2011 12:24:27 -0600
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
-- 
An error is only a mistake if you don't learn from it.
When you learn something from it, it becomes a lesson.


Replies:
Re: [Fwd: Re: stream without asynPort] Dirk Zimoch
References:
[Fwd: Re: stream without asynPort] Dirk Zimoch
Re: [Fwd: Re: stream without asynPort] Eric Norum
Re: [Fwd: Re: stream without asynPort] Ralph Lange

Navigate by Date:
Prev: Re: [Fwd: Re: stream without asynPort] Eric Norum
Next: Re: [Fwd: Re: stream without asynPort] Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: [Fwd: Re: stream without asynPort] Eric Norum
Next: Re: [Fwd: Re: stream without asynPort] Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·