On Mon, Sep 01, 2003 at 10:01:26PM -0400, Peter Chen wrote: > On Friday, Aug 29, 2003, at 01:05 US/Eastern, Rocco Caputo wrote: > > >Sounds good, but also full of problems. It will require a lot of > >maintenance to support different monotonic timer functions for each > >operating system. > > Maybe the better thing to do is to use a standard API such as > POSIX::times as a default. This solves the problem uniformly for > platforms that have *proper* implementations of POSIX. This is > probably preferable to using a non-portable Linux specific interface > such as /proc/uptime. In cases where a monatomic increasing > POSIX::times does not exist, support can be added for a platform > specific monatomic timer.
It's not possible to map times() back to time() in any meaningful way. The times() timer runs at some factor of realtime, so it has a tendency to overflow. When it wraps back to 0, all meaning between times() and time() is lost. Especially if it wraps back multiple times. > Is there any particular advantage of replacing ST_TIME w/ ST_ALARM? > ST_TIME uses the old system time based semantic. Isn't what we are > trying to do here simply to add a "delay" based semantic? How about > keeping ST_TIME and adding ST_DELAY? It saves me headaches later when I try to remember what ST_TIME means. Having the event types match their API names makes things that much clearer. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
