Re: Parallel(?) programming with python
Dennis Lee Bieber wrote at 2022-8-10 14:19 -0400: >On Wed, 10 Aug 2022 19:33:04 +0200, "Dieter Maurer" > ... >>You could also use the `sched` module from Python's library. > >Time to really read the library reference manual again... > > Though if I read this correctly, a long running action /will/ delay >others -- which could mean the (FFT) process could block collecting new >1-second readings while it is active. It also is "one-shot" on the >scheduled actions, meaning those actions still have to reschedule >themselves for the next time period. Both true. With `multiprocessing`, you can delegate long running activity to a separate process. -- https://mail.python.org/mailman/listinfo/python-list
Re: Parallel(?) programming with python
Please let me know if that is okay. On Wed, Aug 10, 2022 at 7:46 PM <2qdxy4rzwzuui...@potatochowder.com> wrote: > On 2022-08-09 at 17:04:51 +, > "Schachner, Joseph (US)" wrote: > > > Why would this application *require* parallel programming? This could > > be done in one, single thread program. Call time to get time and save > > it as start_time. Keep a count of the number of 6 hour intervals, > > initialize it to 0. > > In theory, you are correct. > > In practice, [stuff] happens. What if your program crashes? Or the > computer crashes? Or there's a Python update? Or an OS update? Where > does all that pending data go, and how will you recover it after you've > addressed whatever happened? ¹ > > OTOH, once you start writing the pending data to a file, then it's an > extremely simple leap to multiple programs (rather than multiple > threads) for all kinds of good reasons. > > ¹ FWIW, I used to develop highly available systems, such as telephone > switches, which allow [stuff] to happen, and yet continue to function. > It's pretty cool to yank a board (yes, physically remove it, without > warning) from the system without [apparently] disrupting anything. Such > systems also allow for hardware, OS, and application upgrades, too > (IIRC, we were allowed a handful of seconds of downtime per year to meet > our availability requirements). That said, designing and building such > a system for the sakes of simplicity and convenience of the application > we're talking about here would make a pretty good definition of > "overkill." > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Parallel(?) programming with python
Thanks again for the info. On Wed, Aug 10, 2022 at 9:31 PM Peter J. Holzer wrote: > On 2022-08-10 14:19:37 -0400, Dennis Lee Bieber wrote: > > On Wed, 10 Aug 2022 19:33:04 +0200, "Dieter Maurer" > > > declaimed the following: > > >Schachner, Joseph (US) wrote at 2022-8-9 17:04 +: > > >>Why would this application *require* parallel programming? This > > >>could be done in one, single thread program. Call time to get time > > >>and save it as start_time. Keep a count of the number of 6 hour > > >>intervals, initialize it to 0. > [...] > > Though if I read this correctly, a long running action /will/ > > delay others -- which could mean the (FFT) process could block > > collecting new 1-second readings while it is active. > > Certainly, but does it matter? Data is received from some network > connection and network connections often involve quite a bit of > buffering. If the consumer is blocked for 3 or 4 or maybe even 20 > seconds, the producer might not even notice. (This of course depends > very much on the details which we know nothing about.) > > hp > > -- >_ | Peter J. Holzer| Story must make more sense than reality. > |_|_) || > | | | h...@hjp.at |-- Charles Stross, "Creative writing > __/ | http://www.hjp.at/ | challenge!" > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
