Non-blocking input on windows, like select in Unix

J

Jonathan Fine

Hello

I have written a program that interacts with a
command line program.

Roughly speaking, it mimics human interaction.
(With more speed and accuracy, less intelligence.)


It works fine under Linux, using select().

But Windows does not support select for files.
Only for sockets.

Here's a google search on this topic.

<http://groups.google.co.uk/groups?q...group=comp.lang.python&scoring=d&start=0&sa=N>


I'd like my program to work under Windows also.

I'm exploring the following approach.
stdin, stdout = os.popen2('tex')

Now read a byte at a time from stdout.

Whenever a prompt string from TeX appears,
write the response to stdin.

An experiment at the Python command line shows
that this works. At each step either
a) we can read one byte from stdout w/o blocking
or
b) we can usefully write to stdin.

By the way, this experiment is rather tedious.
Still, I hope to have my computer do this for me.


So, unless I'm mistaken, I can get the program to
work under Windows. Though reading a byte at a
time might give a performance penalty. Can't say
yet on that.

My question is this: Under Windows, is it possible
to read as many bytes as are available from stdout,
without blocking?

This is one way to improve performance. (If needed.)

Another way, is to use _longer_ prompt strings.

If prompt strings are at least 64 bytes long, then
we can safely read 64 bytes -- unless we are in
the process of reading what might be a prompt
string.

This will of course increase performance in the
limiting case of when there are zero prompt
strings, and expensive system calls.


This problem of non-blocking input on Windows seems
to arise often. I hope my remarks might be helpful
to others. Certainly, I've found it helpful to
write them.
 
P

Paul Rubin

Jonathan Fine said:
My question is this: Under Windows, is it possible
to read as many bytes as are available from stdout,
without blocking?

I think Windows implements non-blocking i/o calls. However the
traditional (to some) Python or Java approach to this problem is
to use separate threads for the reader and writer, and let them block
as needed.
 
J

Jonathan Fine

Paul said:
I think Windows implements non-blocking i/o calls. However the
traditional (to some) Python or Java approach to this problem is
to use separate threads for the reader and writer, and let them block
as needed.

Thank you for this.

As I recall, some posts to this list say that Windows provides
non-blocking i/o for sockets but not for files.

However, if non-blocking i/o for files were available, that
would be great. Actually, all I care about is input.

Can anyone provide a definite answer to this question?

And please, if the answer is YES (hope it is), with
working sample code.


The threaded approach does not help me. If the read blocks,
I do not know what to write. (I am responding to a command
line prompt - I have to read it first.)
 
F

fraca7

Jonathan Fine a écrit :
Paul Rubin wrote:
As I recall, some posts to this list say that Windows provides
non-blocking i/o for sockets but not for files.

No, Windows does provide non-blocking I/O for regular files, but it's a
completely different mechanism than the one used by winsock. You'll have
to use win32all and enter the Dark Side, that is Windows APIs.

You don't want to do that if you're not already familiar with
CreateProcess, CreatePipe, overlapped structures, WaitForSingleObject &
al...
 
J

Jonathan Fine

fraca7 said:
Jonathan Fine a écrit :



No, Windows does provide non-blocking I/O for regular files, but it's a
completely different mechanism than the one used by winsock. You'll have
to use win32all and enter the Dark Side, that is Windows APIs.

You don't want to do that if you're not already familiar with
CreateProcess, CreatePipe, overlapped structures, WaitForSingleObject &
al...


Thank you for this.

My application will, I think, become much more complicated if I cannot
use non-blocking input. (As already explained, it is not a problem
that can be solved by threads. Basically, I _need_ either to read
all available data, _or_ to read very carefully a byte at a time.)

Knowing that non-blocking input can be done under Windows, I would
like to use it. In the longer run, that will be easier than
rewriting my application. Or so it seems to me.

I did a google search, on the web, for
CreateProcess, CreatePipe, overlapped structures, WaitForSingleObject

This is the first page is produced
http://www.codeproject.com/threads/anonpipe1.asp

Seems to be the right sort of thing. But I don't have time to read it
now.

I'm not really a Windows programmer. Don't know the system calls.

But I do want my application to run on Windows.

I'll get back to this in a couple of weeks. (Busy right now.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top