Experimental Physics and Industrial Control System
Andrew Johnson wrote:
It's just that it doesn't seem to make much sense to pass the
'process' pointer out there - or do I miss something essential here?
I believe it's there for subroutines that want to cause asynchronous
processing - if the user subroutine sets psub->pact true before
returning because of a background I/O operation, it will need to call
the record's process() routine again when that I/O operation is
complete. Passing it into the init subroutine is simpler for the user
than requiring them to look up the process routine than using a
construct that may at one time have been
(((struct rset*)psub->rset)->process)(psub);
which is a bit ugly and complicated if someone is new to C programming.
The cast is no longer needed, but it might have been back in the old
GTACS days.
- Andrew
The dbCommon field rset did not initially exist. That is probably why the second
argument is passed to the inam routine. The entire code for calling the iname
routine looks strange.
if(strlen(psub->inam)!=0) {
/* convert the initialization subroutine name */
psub->sadr = (void *)registryFunctionFind(psub->inam);
if(psub->sadr==0) {
recGblRecordError(S_db_BadSub,(void *)psub,"recSub(init_record)");
return(S_db_BadSub);
}
/* invoke the initialization subroutine */
psubroutine = (SUBFUNCPTR)(psub->sadr);
status = (*psubroutine)(psub,process);
}
Note that sadr is later used to store the address of the snam routine. I think
the above code should be:
if(strlen(psub->inam)!=0) {
/* convert the initialization subroutine name */
psubroutine = (void *)registryFunctionFind(psub->inam);
if(psubroutine ==0) {
recGblRecordError(S_db_BadSub,(void *)psub,"recSub(init_record)");
return(S_db_BadSub);
}
/* invoke the initialization subroutine */
status = (*psubroutine )(psub);
}
Note that record reference manual never mentions a second argument to the init
routine.
- References:
- subRecord fix Till Straumann
- Re: subRecord fix Andrew Johnson
- Re: subRecord fix Andrew Johnson
- Navigate by Date:
- Prev:
RE: Siemens/Profibus Drivers Robby Tanner
- Next:
timestamp question Kevin Tsubota
- 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
2025
- Navigate by Thread:
- Prev:
Re: subRecord fix Andrew Johnson
- Next:
Labview <-> EPICS Mark M. Ito
- 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
2025