On second thought, it seems like you'd have to create and tear down an IOCP object on every call of sb_select(), and since an IOCP is a notification queue, you'd wind up losing events. Maybe overlapped IO is the only real option?

-Matt Stickney

On Tue, Oct 8, 2013 at 10:13 AM, Matthew Stickney <mtstickney@gmail.com> wrote:
There's a problem on Windows retrieving process output from external programs, namely that something like:

(with-output-to-string (str)
  (sb-ext:run-program "date.exe" '("/t") :search t :output str))

always yields an empty string, despite output from the process. The problem only occurs when the process output is to be copied to an existing stream via serve-event (e.g. with copy-fd-to-stream).

I've poked around a bit, and the issue seems to be that the windows version of sb_select() in runtime/wrap.c uses WaitForMultipleObjects(), but that anonymous pipe handles are not waitable on windows.

I'm not really a windows programmer, but I can think of two possible alternatives:
1. Use an IO Completion Port intead of WaitForMultipleObjects. There might be some threading issues here, and I don't know how expensive it is to create an IOCP object every time sb_select() is called.

2. Request a single-byte overlapped read or write from the handles passed to sb_select(). Overlapped IO calls can be made to generate an event handle that triggers when the IO request completes, and they can be waited on with WaitForMultipleObjects.

I'm posting this here (rather than filing a bug) because I'm not very familiar with SBCL internals, so there may be forces at work I'm not aware of. Any thoughts?

-Matt Stickney