Hi Terry,
> I'm still struggling a bit (well a lot actually ;-) ). The problem is
> still how to get all the things done that I need to get done.
If you keep cycling back over the old emails as you learn more things,
they may make more sense. :-)
> There are a number of references in the code to 'callbacks' (as
> opposed to 'callback'), so I started off thinking that I could add
> multiple callbacks to the GPIO.add_event_detect() statement by listing
> them as you indicated for your example code in your later message that
> I reference below.
IIRC you can't do that.
The C code refers to callbacks for the same reason my example Python
callback example had
callbacks = collections.defaultdict(list)
Because it has to track all the callbacks for all the different events.
It doesn't mean the interface for registering callbacks necessarily
allows multiple ones to be given at once.
> it would probably still not help because the new code needs to run in
> a separate thread, not just the call to it.
Don't know what `new code' is here.
> So, I'm think that what you were leading up in your example to is some
> scheme whereby I set up and create an event handler similar to the one
> you created in this message. This code is run before the
> GPIO.add_event_detect() statements and the callback in each of those
> statements references the appropriate function. These functions are
> where I put my code to change the state of the global control flags,
> kill the mpg321 player and play the message to the user.
No, GPIO provides handle_events(); it was under the `Library code, used
by everyone' comment. You write a bunch of callbacks, register them
all, and forget about it in that main thread, getting on with your timed
chime playing.
You'll end up with this.
python-process
│
├── python-main-thread
│ │
│ └─────/───── quarters-process
│
└── python-gpio-thread
│
├─────/───── bell-player-mpg321-process
├─────/───── playlist-mpg321-process
└─────/───── wedding-sequence-mpg321-process
You run your Python script. That's `python-process' with its own PID,
and it has its python-main-thread running your code. As it stands now,
you're already using a library that tells you when it's on the quarter
and you use the subprocess module to run mpg321. That runs in
quarters-process which is a separate process with its own PID. I've
marked the relationship line with `/' to indicate the process boundary.
On registering callbacks with GPIO, it will create python-gpio-thread,
still in the same python-process. When a GPIO event is seen, it will
block Python in python-main-thread from running and call the matching
Python callback function that you've provided. Your function will be
running in python-gpio-thread, so still in python-process.
A lot of your callbacks will use the subprocess module to run mpg321.
These will again be new processes, just as quarters-process was. Some
will .call() it, waiting for it to finish, and others will .Popen()
where you Python callback code continues to run without waiting for,
say, bell-player-mpg321-process, to finish. You callback will finish,
having kicked off mpg321, and you'll return to the C code in
python-gpio-thread that called you. That will release Python's GIL and
your Python code in python-main-thread is free to continue if it needs.
Cheers, Ralph.
--
Next meeting: Bournemouth, Tuesday, 2017-03-07 20:00
Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/
New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
