Why is StdinWrite() blocking...

[KaFu]

Hiho,

my post in the general question went unanswered, so maybe this is the place to ask .

It seems that StdinWrite() blocking sometimes kills my script. Is there a reason why it's not just returning a failure or success, maybe with an optional timeout set?

I tried to come up with a custom alternative, but to be honest I'm not even sure if I'm looking in the right direction. How is the stdio capture from the run command? Run returns a PID, so somehow there has to be an internal pid<>handle translation, or am I wrong? Is it possible to expose this handle and address it directly (e.g. via CreateFile)?

[Valik]

No code, no bug.

There should be no way StdinWrite() blocks. It's done asynchronously to prevent blocking when the target application's stdin buffer is full. You really need to provide an example I can run that demonstrates the problem.

Edit: To answer the other question in your thread, no, AutoIt doesn't internally use anything remotely similar to the screen scraping function nor the complimentary writing functions.

Edited April 14, 2010 by Valik

[KaFu]

No code, no bug.

Never said it is ...

There should be no way StdinWrite() blocks. It's done asynchronously to prevent blocking when the target application's stdin buffer is full. You really need to provide an example I can run that demonstrates the problem.

Now that's the hard part... the script only seldom stalls, couldn't reproduce it intentionally (yet, will try to come up with something). Maybe I'm totally wrong in my assumption, but if I kill the stdio process in the background, the script comes back the live immediately.

Edit: To answer the other question in your thread, no, AutoIt doesn't internally use anything remotely similar to the screen scraping function nor the complimentary writing functions.

Feared so. In MSDN it is documented that CreateFile can be used to access a console. Any short hint on how to get and access the handle of a pid returned by run()?

[Valik]

I stand corrected, it *is* possible for StdinWrite() to block but only if you are writing massive amounts of data. Are you writing massive amounts of data? Writing is not handled asynchronously, only reading, so, if you write more data than the program can read then the writer (AutoIt) will be blocked.

Feared so. In MSDN it is documented that CreateFile can be used to access a console. Any short hint on how to get and access the handle of a pid returned by run()?

I'm not sure what you are aiming at here. Why are you interested in obtaining the handles?

[jvanegmond]

How much data are we talking about?

Edit: Posted same time as Valik. I've seen before that it blocks when you try passing a crapload of data.

Edited April 14, 2010 by Manadar

[KaFu]

I'm not sure what you are aiming at here. Why are you interested in obtaining the handles?

I wanted to give CreateFile and WriteFile a try, as I assume it will return an error if the buffer is full, thus not blocking the script.

In AMT I use stdinwrite() to sent commands to mplayer.exe, and sometimes (corrupted movie files?) it just stalls and I fear it's not the ammount of data that is choking the process (short commands, some bytes only). The easiest way I see atm is to kill the process if I detect that it's not accepting stdinwrite() and re-invoke mplayer.exe.

[Valik]

I wanted to give CreateFile and WriteFile a try, as I assume it will return an error if the buffer is full, thus not blocking the script.

It's clear you know absolutely nothing about how any of this stuff works. We already use WriteFile(), it blocks. MSDN clearly states the conditions under which it blocks. There's plenty of information on the internet - including the MSDN example used as a base to build AutoIt's current STDIO implementation - on how to perform STDIO redirection.

In AMT I use stdinwrite() to sent commands to mplayer.exe, and sometimes (corrupted movie files?) it just stalls and I fear it's not the ammount of data that is choking the process (short commands, some bytes only). The easiest way I see atm is to kill the process if I detect that it's not accepting stdinwrite() and re-invoke mplayer.exe.

I don't know why the program would block. AFAIK the input is buffered by the OS so even if the target process is not responding, the OS should still continue to buffer until the buffer is full in which case it would block. It's possible the program disabled buffering but I can't think why they would.

I suspect you're either barking up the wrong tree or there's something you haven't told us. At any rate maybe I should change writing to asynchronous (either via threads or the API itself) since there's a small potential for deadlocks with the current code.

[bo8ster]

I many be complete wrong but is there a requirement to flush the buffer?

I remembering having to using fflush() in C/C++ all the time when using a buffer or stream.

Edit: typos

Edited April 21, 2010 by bo8ster

[Valik]

No.