Jump to content

Why is StdinWrite() blocking...


KaFu
 Share

Recommended Posts

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

Link to comment
Share on other sites

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 by Valik
Link to comment
Share on other sites

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()?
Link to comment
Share on other sites

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?
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by bo8ster

Post your code because code says more then your words can. SciTe Debug mode - it's magic: #AutoIt3Wrapper_run_debug_mode=Y. Use Opt("MustDeclareVars", 1)[topic="84960"]Brett F's Learning To Script with AutoIt V3[/topic][topic="21048"]Valuater's AutoIt 1-2-3, Class... is now in Session[/topic]Contribution: [topic="87994"]Get SVN Rev Number[/topic], [topic="93527"]Control Handle under mouse[/topic], [topic="91966"]A Presentation using AutoIt[/topic], [topic="112756"]Log ConsoleWrite output in Scite[/topic]

Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...