EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: recDynLink.c for R3.14.1 ?
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Thu, 17 Apr 2003 01:26:58 +0200
Marty Kraimer wrote:
> 
> Benjamin Franksen wrote:
> > Hi Marty (and all),
> >
> > one important limitation (at least in 3.13.x) is missing in appDevGuide:
> >
> >       dbNotifyCancel must not be called from interrupt context.
> >
> > I did and very bad things happened. BTW, i wonder what will happen if
> > such a record (i.e. one with asynch soft support) is processed as a
> > result of a ca_put_calback. Hmmm...
> 
> VERY few things can be called from interrupt context.
> The Application Developer's Guide says if a routine can get called from
> interrupt routines. If it does not say this it should be assumed that the
> routine can't be called from interrupt context.

Correct. It was stupid of me to assume that calling dbNotifyCancel from
the interrupt routine was safe. I simply didn't think about it.

> Note that the following can be called from interrupt level
> 
> callbackRequest
> callbackRequestProcessCallback
> scanIorequest
> 
> One of these should be all you need. For example callbackRequest can cause a
> user supplied routine to be called by a general purpose callback thread.

That's exactly what i did, then, and it immediately worked fine.

Cheers,
Ben

PS: I finally understood the S_db_Blocked issue (after reading the code
in base and then re-reading the doc): S_db_Blocked is only returned if
an existing put notify block in the target record is the *same* object
(address comparison) as the one that is now being given as argument.
Multiple putNotifies to the same target record seem to be no problem at
all as long as they come from different clients, otherwise they are
ignored. This is make sense, indeed. The Developer's Guide could be a
little more clear on this point; it says "If a putNotify is already
active..." which is of course fine if one already knows what is meant.

Replies:
Re: recDynLink.c for R3.14.1 ? Marty Kraimer
Re: recDynLink.c for R3.14.1 ? Tim Mooney
References:
RE: recDynLink.c for R3.14.1 ? Feng, Shuchen
Re: recDynLink.c for R3.14.1 ? Tim Mooney
Re: recDynLink.c for R3.14.1 ? Kate Feng
Re: recDynLink.c for R3.14.1 ? Benjamin Franksen
Re: recDynLink.c for R3.14.1 ? Marty Kraimer
Re: recDynLink.c for R3.14.1 ? Benjamin Franksen
Re: recDynLink.c for R3.14.1 ? Marty Kraimer

Navigate by Date:
Prev: Contact for EPICS Collaboration Meeting in June Michael Oothoudt
Next: macTest Kevin Tsubota
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  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: recDynLink.c for R3.14.1 ? Marty Kraimer
Next: Re: recDynLink.c for R3.14.1 ? Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·