Re: [gforth] Working example of tasker.fs use

[Bernd Paysan]

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/