By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,394 Members | 1,443 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,394 IT Pros & Developers. It's quick & easy.

Non-blocking input on windows, like select in Unix

P: n/a
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=select+windows+non-blocking&hl=en&lr=&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.
--
Jonathan
http://www.pytex.org

Jul 18 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Jonathan Fine <jf***@pytex.org> writes:
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.
Jul 18 '05 #2

P: n/a
Paul Rubin wrote:
Jonathan Fine <jf***@pytex.org> writes:
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.


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.)

--
Jonathan

Jul 18 '05 #3

P: n/a
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...
Jul 18 '05 #4

P: n/a
fraca7 wrote:
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...

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.)
--
Jonathan

Jul 18 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.