[#41278] [BUG:1.9] BINARY should not be ASCII-compatible — Yugui <yugui@...>

WXVndWkbJEIkRyQ5ISMbKEIKCgo+IBskQiRHISIkKiQqJGAkTSQzJDMkXiRHJE41RE9AJEclKyVQ

15 messages 2010/05/11

[#41407] [Bug #3339] win32ole test failure — Usaku NAKAMURA <redmine@...>

Bug #3339: win32ole test failure

20 messages 2010/05/25
[#41411] Re: [Bug #3339] win32ole test failure — Masaki Suketa <masaki.suketa@...> 2010/05/25

助田です。

[#41412] Re: [Bug #3339] win32ole test failure — "U.Nakamura" <usa@...> 2010/05/25

こんにちは、なかむら(う)です。

[ruby-dev:41205] Re: MonitorMixin::ConditionVariable#wait timeout

From: Yusuke ENDOH <mame@...>
Date: 2010-05-06 14:08:26 UTC
List: ruby-dev #41205
遠藤です。

2010年5月6日20:13 Tanaka Akira <akr@fsij.org>:
> 2010年5月6日19:58 Yusuke ENDOH <mame@tsg.ne.jp>:
>
>> Mutex.sleep は pthread_cond_timedwait で実装されているため、API 上で
>> relative time を受け取ってもシステムクロック変更対策は実現できないの
>> ではないでしょうか。
>
> そうですね。
> relative time で受け付ける機能数がある環境でしか完全には実現できない
> かもしれません。
> (MacOS X の pthread_cond_timedwait_relative_np とか?)
>
> そういう環境では正しく動き、そうでない環境では残念ですが
> 時刻を巻き戻した場合は遅くタイムアウトすることになるでしょう。
>
> しかし、absolute time しか指定できなければ、
> 遅くタイムアウトしないという機能を提供することは不可能です。


考えてみたら、relative time を指定しても、spurious wakeup した場合に、
システムクロックが信頼できないとなると、あとどれだけ wait すべきなのか
計算できない気がしました。

「あとどれだけ wait すべき」という情報もあわせて教えてくれる機能が
ある環境って存在するんですかね。

-- 
Yusuke Endoh <mame@tsg.ne.jp>

In This Thread