EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  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  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: ASYN - calling read after interrupt - fix :)
From: "Mark Rivers" <[email protected]>
To: "Eric Norum" <[email protected]>, <[email protected]>
Cc: [email protected]
Date: Thu, 11 Oct 2007 08:37:26 -0500
> Thus your request for a configurable interrupt queue is somewhat 
> orthogonal to the topic although I agree that it is a good idea to 
> provide configurable sizes to interrupt handlers which use message 
> queues.

 
Eric is correct.  The queuing would all be done in the asyn driver, typically a message queue between the interrupt function and the thread that handles callbacks.  This is how my existing asyn interrupt drivers work.
 
Thus, if user-specified queue sizes are desired then the driver author would need to provide a way to configure that in the driver creation/configuration routine that is called from the startup script.
 
Mark
 

________________________________

From: [email protected] on behalf of Eric Norum
Sent: Thu 10/11/2007 8:28 AM
To: [email protected]
Cc: [email protected]
Subject: Re: ASYN - calling read after interrupt - fix :)




On Oct 11, 2007, at 4:05 AM, Benjamin Franksen wrote:
>
>
> I agree with Mark and Eric. It may not be a problem in /most/ 
> situations if
> interrupt are lost. However, there may be cases where this is a 
> problem. I
> can imagine a card wants to acknowlege completion of a long runnign
> operation by issuing an interrupt. If multiple channels per card are
> involved, and each one gets its own completion interrupt, we'll have a
> problem indeed. Always remember Murphy's law ;-)
>
> BTW, if solution 2 gets implemented, I'd make sure the interrupt 
> queue size
> can be configured by the user.
>

I think that Mark's proposal 2 makes no changes to the way interrupt-
level code passes information to the ASYN callback thread.  If I 
understand properly, what he is proposing is to have the ASYN 
callback thread lock the record and process the record directly 
rather than having a scanIOrequest callback thread to do this work.

Thus your request for a configurable interrupt queue is somewhat 
orthogonal to the topic although I agree that it is a good idea to 
provide configurable sizes to interrupt handlers which use message 
queues.

--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793






References:
RE: ASYN - calling read after interrupt - fix :) Mark Rivers
RE: ASYN - calling read after interrupt - fix :) Heinrich du Toit
Re: ASYN - calling read after interrupt - fix :) Benjamin Franksen
Re: ASYN - calling read after interrupt - fix :) Eric Norum

Navigate by Date:
Prev: RE: firewire video on RTEMS-4.6.x-MVME5500 Mark Rivers
Next: StreamDevice 2-3 released Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: ASYN - calling read after interrupt - fix :) Eric Norum
Next: RE: ASYN - calling read after interrupt - fix :) Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Nov 2011 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·