Re: [Sbcl-devel] Windows sb-ext:run-program output issue

[Matthew S. <mts...@gm...>]

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 <mts...@gm...>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
>