FD_CLOEXEC を fd 生成と同時に (atomic に) つける方法は、Austin Group Defect Tracker の以下のエントリで扱われている。(open の O_CLOEXEC と fcntl の F_DUPFD_CLOEXEC はすでに規格 (SUSv4) に入っているので、それ以外を次の規格で変えるという話を track しているのがここなのだと思う)
adding atomic FD_CLOEXEC support - Austin Group Defect Tracker
まとめると、以下のようになる。
以下には Linux 固有のシステムコールについて FD_CLOEXEC を atomic につける話も載っている。
Secure File Descriptor Handling
ndbm について考古学してみる。しかし、gdbm は 1.5 より前のが見つからない。
bug-gdbm のアーカイブはないのかな。
gdbm 1.10 が出たようだ。
頼んだかいがあって O_CLOEXEC サポートが入っている。
長年 test_sleep_5sec が boron で失敗してきたが、どのくらい失敗してきたのか。
sleep 5 が 5±0.1秒で起きる、というテストだが、失敗した時はテストの結果に秒数が出るので、chkbuild のログからかき集めて以下のようなデータを作った。
% head 2011-11/sleep.csv date,slept 20080730T223301,5.12672618 20080731T192805,5.15294989 20080801T002201,5.882326055 20080802T230600,5.2600416 20080803T104900,5.964888311 20080805T181910,5.68200147 20080810T043900,5.164079106 20080810T224400,10.493473688 20080811T214900,5.282592791
時系列のグラフにしてみる。
sleep.R:
library(ggplot2) d <- read.csv("2011-11/sleep.csv") d$date <- as.POSIXct(d$date, format="%Y%m%dT%H%M%S") print(qplot(date, slept, data=d))
頻繁に失敗する時期とそうでもない時期がある感じ?
時系列を無視してヒストグラムにしてみる。
sleep-hist.R:
library(ggplot2) d <- read.csv("2011-11/sleep.csv") d$date <- as.POSIXct(d$date, format="%Y%m%dT%H%M%S") print(qplot(slept, data=d))
大半は 6秒以内に終わっているが、最悪は12秒を越えるケースもある。
kernel の違いは関係あるだろうか?
例によって chkbuild のログからかき集める。
% head 2011-11/sleep-kern.csv date,slept,kernel 20080730T223301,5.12672618,2.6.18-6-686 20080731T192805,5.15294989,2.6.18-6-686 20080801T002201,5.882326055,2.6.18-6-686 20080802T230600,5.2600416,2.6.18-6-686 20080803T104900,5.964888311,2.6.18-6-686 20080805T181910,5.68200147,2.6.18-6-686 20080810T043900,5.164079106,2.6.18-6-686 20080810T224400,10.493473688,2.6.18-6-686 20080811T214900,5.282592791,2.6.18-6-686
sleep-kern.R:
library(ggplot2) d <- read.csv("2011-11/sleep-kern.csv") d$date <- as.POSIXct(d$date, format="%Y%m%dT%H%M%S") print(qplot(date, slept, color=kernel, data=d))
べつに関係ないか...
CPU との関係もみてみたいところだが、記録してないんだよな。
[latest]