Queues are better than lists for concurrency. If you get the right kind, they have implicit locking, making your code simpler and more robust at the same time.
CPython threading is mediocre for software systems that have one or more CPU-bound threads, and your FFT might be CPU-bound. Rather than using threading directly, you probably should use https://docs.python.org/3/library/concurrent.futures.html , which gives you easy switching between threads and processes. Or if you, like me, get inordinately joyous over programs that run on more than one kind of Python, you could give up concurrent.futures and use _thread. Sadly, that gives up easy flipping between threads and processes, but gives you easy flipping between CPython and micropython. Better still, micropython appears to have more scalable threading than CPython, so if you decide you need 20 CPU-hungry threads someday, you are less likely to be in a bind. For reading from a socket, if you're not going the REST route, may I suggest https://stromberg.dnsalias.org/~strombrg/bufsock.html ? It deals with framing and lengths relatively smoothly. Otherwise, robust socket code tends to need while loops and tedious arithmetic. HTH On Mon, Aug 8, 2022 at 10:59 AM Andreas Croci <andrea.cr...@gmx.de> wrote: > I would like to write a program, that reads from the network a fixed > amount of bytes and appends them to a list. This should happen once a > second. > -- https://mail.python.org/mailman/listinfo/python-list
