gforth
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anton Ertl
Subject: Re: [gforth] Working example of tasker.fs use
Date: Tue, 16 Dec 2014 08:31:39 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Dec 15, 2014 at 10:45:09PM +0100, Bernd Paysan wrote:
> 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?).

DEADLINE sounds good.  One would naturally use it with UTIME (or
something like it), so either we make DEADLINE accept microseconds, or
we add NSTIME to produce nanoseconds.

>  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 ;-).

My guess is that the idea is that there are usually no threads that
wait for both an absolute deadline and some other event; so threads
that wait for an absolute deadline, use pthread_cond_timedwait(),
others use select() or poll() or something.

We can implement the absolute timeout with a relative one:

: deadline ( d -- )
  utime d- dup 0> if us else 2drop then ;

where US ( d -- ) is a microsecond variant of MS.

This is a little imprecise, but as we don't have drift, this should
not really matter.  One might correct for the time spent between UTIME
and US if that's an issue.

> 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.

Are we in the word-savers club?  That's as idiotic as F~.  Such
trickery is only justified if we want to reconcile two existing
conflicting usages of NS, but that's not the case here.  Just have NS
(or US) for relative deadlines (analogous to MS), and DEADLINE for
absolute ones.

- anton



reply via email to

[Prev in Thread] Current Thread [Next in Thread]