日々の流転

λ. コンパイル猿

gtk_main()にたどり着いているって事は、Windowsメッセージでマズイ事になってるという可能性がありそうだ。

探してみると、glib/gmain.cのg_poll()が、G_OS_WIN32が定義されているかどうかで二つに分かれていて、ここにG_WIN32_MSG_HANDLEを処理する部分がある。ただ、ここで悩ましいのはGPollFDの扱いだよなぁ。当然今はfile descriptorが入っているのだけど……

On Win32, the fd in a GPollFD should be Win32 HANDLE (*not* a file descriptor as provided by the C runtime) that can be used by MsgWaitForMultipleObjects. This does *not* include file handles from CreateFile, SOCKETs, nor pipe handles. (But you can use WSAEventSelect to signal events when a SOCKET is readable).

On Win32, fd can also be the special value G_WIN32_MSG_HANDLE to indicate polling for messages. These message queue GPollFDs should be added with the g_main_poll_win32_msg_add function.

But note that G_WIN32_MSG_HANDLE GPollFDs should not be used by GDK (GTK) programs, as GDK itself wants to read messages and convert them to GDK events.

So, unless you really know what you are doing, it's best not to try to use the main loop polling stuff for your own needs on Win32. It's really only written for the GIMP's needs so far.

さて、fdtab[fd]->get_handle() で Cygwin の file descriptor から Win32のHANDLEを得られると考えて良いとしたら、select()は使わないで、全部HANDLEに変換してMsgWaitForMultipleObjects()するのが良いかもしれない。しかし、fhandler_baseのget_handle(), get_io_handle(), get_output_handle() はどう使い分ければ良いのだろう。……と思ったら、これらはcygwin1.dll内部専用か。ちぇっ。

というか、そもそもCygwinは自前のpoll()を持っているので、glib/gmain.cのg_poll()は最初から使われていなかったのね。g_poll()をいじってどうこうしようとしてたのはそもそも筋が悪かったわけか。

gdk/win32/gdkevent-win32.cの方でGSourceをもっとちゃんと使えば、多少効率は落ちても、poll()の置き換えなしに出来るんじゃないかという気もする。この辺りのソースをきちんと読まないといかんかなぁ……

λ. PRIMES is in P

今更だけど印刷してみた。僕の周りでは概ね好意的な反応ばかりなので、あけてくれ日記 2002.08.17(土) の「真っ赤な嘘」という記述が気になっています。