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