in reply to Re^2: [Win32] IO::Select's can_read method
in thread [Win32] IO::Select's can_read method

Unix select behaviour for pipes could be emulated on Win32 using PeekNamedPipe().

Although the function name suggests that this is design for use with named pipes, it also works with anonymous pipes:

hNamedPipe in

A handle to the pipe. This parameter can be a handle to a named pipe instance, as returned by the CreateNamedPipe or CreateFile function, or it can be a handle to the read end of an anonymous pipe, as returned by the CreatePipe function. The handle must have GENERIC_READ access to the pipe.

Similarly, can_read() could be implemented for files using Alertable IO, and callbacks placed on the Asynchronous Procedure Queue.

Implementing either would require a substantial rewrite of win32_select() in win32sck.c


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Replies are listed 'Best First'.
Re^4: [Win32] IO::Select's can_read method
by Corion (Patriarch) on Dec 09, 2011 at 11:01 UTC

    The ugly part of Alertable IO is that you will always read (at least) one byte that you can't easily stuff back. I haven't found (by just reading the documentation, not by trying it out) a way that gives you just "you can read n bytes from this filehandle now" or "read as many bytes as are available without blocking" outside of PeekNamedPipe().

      Cygwin deals with the problem by buffering the data. Attempt to do a non-blocking read, do the async IO for the number of bytes the read wanted, if more than X ms passes without a async response (event obj, APC, or IOCP), declare the read failed with EWOULDBLOCK. Until the read completes, every read will fail with EWOULDBLOCK. Its very simple, simply buffer the data internally.

      Select is not that hard to make file aware, you just have to multiplex the async file kernel event objects with the winsock handles. I think winsock handles can goto waitformultiple unmodified unless this is DOS Windows.
        Thanks for the explanation/pointers/elaboration, guys.

        No further questions at this stage - though that might change as I delve further into the project.

        (There's currently a PDL-Graphics-Gnuplot implementation which works well on nix type systems (and Cygwin) ... and works to a certain extent on Windows. Gnuplot seems pretty cool, and a fully functional Windows port would be good.)

        Cheers,
        Rob
      The ugly part of Alertable IO is that you will always read (at least) one byte that you can't easily stuff back.

      For files, it essentially mean buffering the input within the application. Select for unix must do the same thing, though the buffering is probably done by the OS rather than in user space. For files, 'put back' simply means a negative seek.

      For pipes, the data has to have been received and therefore buffered before any OS can tell it it can read. PeekNamedPipe() just allows to to find out how much (and what, but that's by the by) has been received and buffered.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?