How Autoit Support Nonblocking Read from Stdin

[BruceCopperField]

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

[jvanegmond]

You could check the AutoIt C++ source code. You can find it here: http://www.autoitscript.com/autoit3/files/...-v3.1.0-src.exe

[Jon]

You could check the AutoIt C++ source code. You can find it here: http://www.autoitscript.com/autoit3/files/...-v3.1.0-src.exe

It's a recent change, it won't be in there.

[Valik]

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

[BruceCopperField]

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.

[Valik]

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 November 14, 2008 by Valik