There's a problem on Windows retrieving process output from external programs, namely that something like:
(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?