[Top][All Lists]

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

Re: [MIT-Scheme-devel] feature request

From: naruto canada
Subject: Re: [MIT-Scheme-devel] feature request
Date: Tue, 16 Sep 2008 19:59:45 +0000

On 9/16/08, naruto canada <address@hidden> wrote:
> On 9/16/08, Taylor R Campbell <address@hidden> wrote:
>>    Date: Tue, 16 Sep 2008 18:45:12 +0000
>>    From: "naruto canada" <address@hidden>
>>    On 9/16/08, naruto canada <address@hidden> wrote:
>>    > On 9/16/08, naruto canada <address@hidden> wrote:
>>    >> On 9/16/08, Taylor R Campbell <address@hidden> wrote:
>>    >>> What does %N mean?  It's not a standard strftime(3) format.
>>    >
>>    > It means nansecond.
>>    typo, nanoseconds.
>> Thanks.  There is currently support in MIT Scheme for nanosecond-
>> resolution clocks; the best you get is microsecond resolution from
>> gettimeofday(2) with the nullary REAL-TIME-CLOCK procedure, although
>> it yields a number relative to the start of the process.  Adjusting
>> this to get a number of microseconds relative to some epoch is a
>> simple matter of programming, but since you wanted to combine it with
>> the number of seconds since the epoch anyway, this doesn't matter
>> much.
> with a 2G cpu and the threading speed of linux I would still worry
> about two processes getting the same number with microsecond
> resolution. It's unlikely but still possible, that only 2000 clock
> could have switch two processes on a linux machine.

I just thought of a better idea, if mit-scheme's tcp socket works, I
can simply write a few lines of perl codes for a gensym server, and
syncronize the increment of counter this way.


reply via email to

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