Sign in to follow this  
Followers 0
BruceCopperField

How Autoit Support Nonblocking Read from Stdin

6 posts in this topic

This was posted in General Help and Support but I think here is the right place so I re-post it here.

StdoutRead() in Autoit is a non blocking function. I've checked some Windows programming textbook and it says anonymous pipe (which I think corresponds to the redirected stdio/stdout between 2 processes) cannot be made in non-blocking mode. I just want to know how Autoit itself achieves a nonblocking read from the redirected stdin.

I am actually trying to write a C program which read from its stdin in a nonblocking manner. However, all the ANSI C standard I/O library calls are blocking (it stops and wait for data from stdin). Could anyone provide some hints to me. Thx for your help

Share this post


Link to post
Share on other sites



I'm a genius? Really, though, it's not that hard to figure out how it's done.

Share this post


Link to post
Share on other sites

The way I'd do it in Windows is to create a new thread listening on the stdin in blocking mode and update a shared structure between the main and the listening thread. And, the main thread just read from

this shared structure. But this would seems to be an overkill for such a tiny little functionality. In *nix, as I recall ioctl() or fctnl() should be able to made the stdin non-blocking. I'd expect something similiar in Windows but couldn't find it.

I'm not sure if Autoit is doing something similiar.

Share this post


Link to post
Share on other sites

#6 ·  Posted (edited)

I don't know if I'd call it overkill. It's more than just non-blocking. Non-blocking is really a bonus. A more important aspect, at least for AutoIt, is a guarantee against deadlocks due to full stream buffers. That means it's safe to start a process and let it run to completion without having to worry about reading the stream on the fly. The previous iteration of STDIO functionality - more specifically the code written to use it - was a deadlock waiting to happen. Most code had a loop reading STDOUT first and after that was done it would read STDERR. In theory if enough data was sent to STDERR while the script was still in the first loop then both processes would deadlock. The other is what I mentioned above, reading after a process is closed. A lot of the time these spawned programs only run for a few milliseconds so it makes sense to start them, wait for them to close and then read the streams. But again, if a lot of data was sent over the pipe, it would deadlock both processes. So my solution, which you've already guessed at and deemed overkill for your needs wasn't really to make the functions non-blocking but rather to make them non-deadlocking.

Anyway, it's really easy to answer the question. Just call Run() with STDIO redirection and see if any new threads are created. That would be the most simple test rather than ask us.

Edit: Fixed typo.

Edited by Valik

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0