While I do understand how I can use imp.wakeup() or imp.onidle() to "open up" long loops so they don't block, I'm often left feeling that my implementations could have been more elegant. As I'm not so familiar with object oriented languages I'm wondering if I'm missing some tricks that would make things tidier.
One reason that things become untidy to my eye is that variables have to have global scope in order to retain their values over successive calls. Relatively complex process with many parameters that factor into looping calculations (DSP type operations for example) end up requiring lots of global variables. Perhaps I've just developed an irrational dislike of globals.
When I first encountered the requirement for non-blocking imp code I was expecting to see a function along the lines of doEvents() as in VB to temporarily hand back cycles to the OS. I'm curious to know if there was a particular reason to avoid using this kind of mechanism? It certainly doesn't appear to be possible to implement it using the calls available .
One reason that things become untidy to my eye is that variables have to have global scope in order to retain their values over successive calls. Relatively complex process with many parameters that factor into looping calculations (DSP type operations for example) end up requiring lots of global variables. Perhaps I've just developed an irrational dislike of globals.
When I first encountered the requirement for non-blocking imp code I was expecting to see a function along the lines of doEvents() as in VB to temporarily hand back cycles to the OS. I'm curious to know if there was a particular reason to avoid using this kind of mechanism? It certainly doesn't appear to be possible to implement it using the calls available .