On Saturday, February 24, 2018 at 5:20:17 PM UTC-8, Kiwi User wrote:
> On Sat, 24 Feb 2018 15:10:46 -0800, ewholz wrote:
> 
> > I have been considering using an interrupt for this, but question
> > whether or not it will save any thing.
> > Whether or not I use an interrupt, I still have to run the program
> > using:
> > "python my_interrupt.py"  This program will be running all the time. My
> > program called new_monitor.py needs to be invoked the same way.  Do I
> > save anything using interrupt vs. the while loop code?
> >
> It depends on the length of the scan cycle, how many conditions must be 
> checked and how long a signal persists in comparison with the time for a 
> loop to complete.
> 
> Your system will work to monitor your door because its unlikely that the 
> door will be opened and and closed within a second. On the other hand, if 
> you used the same 1 second loop to check for somebody pressing a 
> microswitch or a hand passing through a light beam, then its likely that 
> many events would be missed. The same problem can occur if the action the 
> event triggers takes as long as the loop  cycle  time to complete, then 
> you'd miss other types of events that the loop is scanning for.
> 
> Its better to use interrupts if several events are being monitored and if 
> any of the actions they trigger will take time to complete, but the 
> program structure can become quite a lot more complex. For example, if 
> you're monitoring several interrupt sources and the associated actions 
> are long compared with the maximum rate at which interrupts may occur, 
> then, to avoid missing any interrupts, you may need a multithreaded 
> program which has:
> 
> - a set of threads, each waits for a specific interrupt and, when the
>   interrupt fires, the thread adds an action request to an event queue
>   and then waits on the interrupt monitor for the next one to occur. If
>   its not possible to wait on an interrupt then these threads would scan
>   for an interrupt and, if one is not found, wait a short time before
>   scanning again.
> 
>   If detection is fast and there are only a few interrupt sources then
>   this could be a single loop that scans for interrupts and adds an
>   associated action request to the queue for every interrupt it sees.
>   At the end of the scan list it should wait a short time before
>   repeating the scan.
>   
> - there is only one event queue, organised as a first-in / first-out
>   (FIFO) queue so action requests are held in the same order as they
>   arrive
> 
> - one or more worker threads. Each grabs the next action request off the
>   event queue, carries out the requested action and discards the request.
>   Then it checks to see if the queue is empty. It there is another action
>   request waiting it handles it. If the queue is empty the thread starts
>   a timer and suspends itself. 
> 
> - the timer. When this times out, it adds a wakeup action request to the
>   event queue and stops. 
> 
> - A wakeup action request does nothing: the worker thread grabs it off
>   the queue, discards it and looks for the next request.  
> 
> > Let me know what you think.  I do plan do check the resources used of my
> > inline coded program and then create the same funtionality using the
> > interrupt method.
> >
> As I said above: in the simple case a simple scan loop may do the job, 
> but if there are a lot of things to scan for or dealing with an event 
> takes a long time, then a more complex interrupt handling system may be 
> needed. 
> 
> A 'short wait' might be in the range of 10 - 100 mS for starters and 
> should be tweaked to suit the tasks the program is being asked to do, 
> i.e. shortened if the program is slow to respond to events and lengthened 
> if the program is just spinning and burning mpu cycles while its waiting 
> for something to do.
> 
> 
> -- 
> Martin    | martin at
> Gregorie  | gregorie dot org

Well thanks for this scholarly reply. I have implemented a test program using
an interrupt on a GPIO pin - but have noticed that I was getting "interrupts"
when the door was not being opened or closed. I have since discovered
(complemnts of the internet) 
that Linux interrupts here and there, and thus may cause the bogus messages I
was getting.  The python program does take up some resources, but the Pi is
used only for door open/close events. I have concluded after reading your
treatise, that an 
interrupt implementation is not really practical for my "bush league" program,
and checking, saving, and comparing the newState and lastState is plenty good
enough.

Thanks for all the replies!
ewholz

--- SoupGate-Win32 v1.05