Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
> 
> > Tim, have you looked at doing something in the millisecond clock call?
> Not until recently but it will have to go on my list I guess. Platforms
> that (ab)use UI polling to run their entire multitasking regime are a
> real pain in the neck sometimes!
> 
> Don't forget that checkForInterrupts() does attempt to make sure that
> ioProcess() is called at least once every 500mS. We could make that
> more frequent at some cost in apparent benchmark performance. For
> UIequalsOS task switching platforms this is a useful place to ensure at
> least some UI polling.

I've always wondered why this is not more frequent.  It would be nice on
Unix, too: even though it is possible on Unix to play with getting
asynch signals for various things, or to have background threads
watching over stuff, it is a lot simpler and more portable to have a
single thread that uses select() to check on events.  The one thing that
seems to make it all work is that whenever any kind of event is polled
from the image, all of the event streams get checked.  But that can give
weird performance observations, e.g. disabling Morphic could cause your
sockets performance to go way down.

I guess I'm a sucker for nice architectures, even if they cost in
maximum possible performance.  On Unix a lot of things boil down to
events coming over a file descriptor, and thus it is nice to register
all these file descriptors plus their event handlers and then to have an
aioPoll() function that checks on everything.  Simple simple, and
reasonably fast, and very easy on the CPU.

And on platforms that don't need it, the frequent calls can be toned
down within the function; on platforms that need no polling at all, the
function can be empty.  So I don't know that this would really impact
benchmarks....  one poll per millisecond is very low for a CPU....


-Lex