Am Montag, 15. Dezember 2014, 17:25:13 schrieb Anton Ertl: > On Sat, Dec 13, 2014 at 07:01:12PM -0800, Jerry DeLisle wrote: > > of the tasker to the underlying OS so the infinite loops don't burn CPU > > cycles uselessly. > > Note that in classical Forth multitaskers MS yields (pauses) until the > time has passed, and if no other task wants to do something, the > multitasker busily visits all the tasks. Gforth was originally not > designed for multi-tasking, and had an MS that did not PAUSE; I don't > know if that has changed, but eventually, it should. > > Nowadays one usually wants to save the power and/or leave the CPU to > other processes, and this can be achieved with a bit of additional > complication in the scheduler.
If you want to use a multitasker that's appropriate to a modern CPU, use the pthread-based one. Gives you the right scheduling and utilizes several cores. I've added the missing KILL, so your code seems to work with the thread-based multitasker (though the KILL never gets through, as PAUSE doesn't check for events - this should be fixed; PAUSE can do more than just SCHED_YIELD, and it should definitely check for events). And indeed, we should make ms a deferred word so that different multitaskers can plug in different solutions. BTW: Modern OSes support nanosecond sleeps, so what about having : ms ( n -- ) 1000000 m* ntime d+ ns ; and putting in the actual replacible sleep logic into ns? Actually, the right spec is to define an absolute deadline instead of a relative; we should do that with ns (ANS/Forth200x failed with MS); maybe the name might need to change (ABSTIME-NS? DEADLINE-NS?). pthreads AFAIK has one absolute deadline wait, pthread_cond_timedwait(), but it's still useless (it can't be combined with poll() to wait for other OS events; the only way to use it as such is to have a thread which waits on the OS, and then sends a condition to the thread which waits on abstime - that sounds stupid ;-). Another option could be to use the same interface for relative and absolute times: As we have passed 1.4e18 ns since the start of Unix timers, we could say "every time >1e18ns is an absolute time", and expect that nobody wants to wait for the ~30 years that corresponds to. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
