Orz日記 by Akio Morita

_ [Fortran]libgfortran解析

Fortran I/O側でのバッファ管理の形態は、OPEN文が実行された時点での fileの種類に依存し、実際のI/O時にfile descriptorがどんな 実体と結びついているかは考慮されていない。 つまり、外部から FNUM + dup2(2)で上書きするという使い方は、 保証外の使用法である。(当たり前と言えば、当たり前ですよね)

バッファの管理形態としては、次の3種に分類できる。

• regular file(一般のファイル)では、FGETC intrinsicを使ってもバッファフィルのために read(2)でBlockingが発生する可能性が有る。
• special file(/dev/nullや pipe)の場合は、kernel buffer側が空でなければ、Non-Blocking的な動作をする。
  • ただし、kernel buffer側から Fortran I/Oバッファへ読み込めるだけ読み込む。
  • 結果、I/O intrinsicで要求されたよりも多くのデータがkernel buffer側から読み出され空になる可能性が有る。
• unbuffered(端末デバイス)では、I/O intrinsicの要求された量しか読み出さない。
  • 結果、FGETC intrinsicは 1byte readのシステムコールを発行する。

つまり、SADInspectで起きてる問題は、special file型としてOPEN された Logical Unit Number(LUN)へ socketを結びつけてネットワークから uni-byte streamを受け取る際に、SelectUnit[](ioctl(FIONREAD))で kernel buffer側に溜まっているデータ量を確認し Read[, {n*Byte}]で 溜まっているデータだけを受け取ろうとするが、ioctl(FIONREAD)発行後 read(2)システムコール呼び出しまでに新たに受信されたデータが、 Fortran I/O側のバッファにコピーされ、Read[]で指定した以上の データが kernel bufferから取り出されるために、適切な受信が 出来ない現象であると説明できます。

Fortran I/Oを使う限り、Fortran I/O側のバッファに溜まっている データ量を拾う手段が無いことには解決しません。 また、Fortran I/Oの具体的な実装はコンパイラ依存なので、 言語仕様にそうした手段が組み込まれない限りコードの移植性は望めません。

従って、これを解決するには、unbufferedにするしかありません。 具体的には、itopenbuf_内で仮想端末を確保してOPEN文に渡せばよい。 ただし、FGETCを用いた現状の uni-byte stream読み込みの実装では 著しいパフォーマンス劣化が予測されます。

_ [SAD][Fortran]仮想端末デバイスを使った itopenbuf_

仮想端末デバイスを一時ファイルにした itopenbuf_を実装。

Revision 1482は、USE_NEW_FORTRAN_OPEN_SIM=YESな状態でコンパイルした itopenbuf_はposix_openpt(3),grantpt(3),ptsname(3),revoke(2)を使った 仮想端末デバイスの確保を行いOPEN文でptyを開いたのち、 そのfile descriptorを/dev/nullで置き換えて、 仮想端末をクローズする。

以前のmkfifo(2)ベースの動作に戻すには、 COPTへ-DUSE_ITOPENBUF_MKFIFOを追加こと。

_ [SAD][Fortran]仮想端末デバイスを使った itopenbuf_の効能

仮想端末版 itopenbuf()で作った Logical Unit Numberへ結びつけた pipe(2)での動作を検証してみました。

• g77は、Fortran I/Oのバックエンドが stdioになっている。
  • Pipe[]へのWrite[]もbuffered(Flush[]するまで、kernelに渡らない)なので、これはstdioのバッファリングの挙動と思われる。
• Intel Fortran 8.1は、Pipe[]へのWrite[]はunbufferedな動作になっているのが謎。

Intel Fortranに関しては、最新の Version 10は持ってないので判断を 保留しますが...g77に関しては「窓から投げ捨てろ」ということですね

_ [tDiary]tdiary-2.2.1へ追従

2008/02/29にリリースされていたのね...

_ [Fortran]gfortran 4.4.0 20080314 (experimental)

explの修正が入った。

explを使った long double系の intrinsicは、 explが提供される環境でのみ組み込まれるよう変更されました。

_ [SAD][Fortran]gfortran 4.4.0でコンパイル

20080314の snapshotだと問題なく動作する。 becnh2.sadで見る限り、4.3よりも少し早い？

_ [雑記]今日も風が…

今日も風強めで、土埃が orz

あと、前の時ほどではないが風が生温かい気がする。 また、雨でも降って急に寒くなるのかな？

_ [FreeBSD]ipfwでハマる

stable/13の途上で、Network stackの挙動が変わったぽぃ

NIC上に割り当てたIPv4と lo0にaliasで割り当てたJail用のIPv4間の通信だが、以前はlo0経由だったが、今はNIC側で in/outする模様

Jail側からホスト側のNIC上に割り当てたDNS cache resolver/SMTP serverへのアクセスがipfwのフィルターに引っかかることで発覚した Orz

_ [雑記]Ruby2.7 EoLに向けて…

環境整理作業実施

• tDiary-4.1
  • プラグイン組み込みを見直し
    • 使われていないプラグインを外す・設定削除
    • counterプラグインを外す・ローカルパッチ削除
  • contrib plugin image_ex.rb取り込みと環境設定以外は、標準状態に戻ったはず (確認完了すれば、最新版への更新準備完了のはず)
• Hiki-1.0
  • MathJax v2/3 plugin実装 (add_header_procで挿入するだけだが)
    • v3はマークアップ記号の設定法がv2と違うので、しばらくドキュメントを読み漁ったが…
  • mathwiki style + X-Math pluginから default style + MathJax v3 pluginへ切り替え実施
  • X-Math plugin, MathML library, mathwiki style削除実施
  • comment・footnote・todo・trackback pluginを外す
  • its/comment plugin間で共用化しているNG設定を分離
  • comment pluginのローカルパッチ削除
• テスト環境にruby31 & ruby27を準備 (検証作業用)
• tDiary-5.2.4までをvendor dropに取り込み
• 検証環境作業
  • tDiary-5.2.4/ruby-3.1.3へのアップグレード検証実施・基本動作確認