Prev: How are Windows Connected to Processes?
Next: Apple Sues the HTC (Android phone maker) with Patents that effectsus all
From: Hector Santos on 2 Mar 2010 22:17

IlyaK wrote:

> Thanks Hector.
>
> 1. get_cancel_text() is just an abstraction of a higher level function
> that checks if the user pressed some button. I know I don't block on
> it because2. I stepped through the code with the debugger.
> 2. If you know a better way to do this without piping, let me know. I
> don't need interactive IO.
> 3. I don't prematurely close the processor handle, if the
> hChildProcess != NULL. I do close the main thread handle. Do you think
> this is a problem?


No, you have that right.

> 4. Your code calls ReadFile until it returns false. I tried that, but
> I still get stuck.
> 5 Does it make any difference that I do all this in mfc application?

Depends what you are doing with the message queue and how its called.

This is python? hmmmm, that shouldn't be an issue.

For our web server script map support, the code is very similar and
supports all standard I/O CGI tools.

There are several possible issues and requires:

- The child process must be standard output and
can't be waiting for input.

- If its possible no output, then you need an async
ReadFile (Overlapping I/O) timeout.

Since you said its blocking, then I am guessing the python script is
not returning output and its not quiting.

What is the command you are using?

It worked fine with this simple hello1.py

def greet(name):
print 'hello', name

greet('Jack')
greet('Jill')
greet('Bob')

The code runs:

run("python hello1.py", TRUE);

with the output:

-- Process: F:\WINDOWS\system32\cmd.exe /c python hello1.py
-- waiting
hello Jack
hello Jill
hello Bob
-- finished
-- done

Whats in your get_cancel_text() function?

If you are NOT doing this in multi-threaded fashion, then in your MFC,
when you start it, the queue is not called unless you do it by peeking
into it.

But I didn't even go there, I put the code I posted into a MFC program
with a RUN button, a Edit field and I captured the output into a list
box.

So I suspect maybe your python script perhaps is not returning?

--
HLS
From: Jonathan de Boyne Pollard on 3 Mar 2010 00:14
>
>
> Strange hang problem with ReadFile.
>
You're leaving the write end of a pipe open. Since your variable names
are confusing, and you appear to be duplicating handles for the fun of
it, I've not looked to see which handle(s) this is.

From: IlyaK on 3 Mar 2010 02:03
The write end of the pipe gets closed at the end. Is there a problem
with it open?
All that handle duplication came from the Microsoft's example. I
didn't invent it. If there is a better way, I'll be happy to use it.


On Mar 2, 9:14 pm, Jonathan de Boyne Pollard <J.deBoynePollard-
newsgro...(a)NTLWorld.COM> wrote:
> > Strange hang problem with ReadFile.
>
> You're leaving the write end of a pipe open.  Since your variable names
> are confusing, and you appear to be duplicating handles for the fun of
> it, I've not looked to see which handle(s) this is.

From: IlyaK on 3 Mar 2010 02:26
Hi Hector:

I'll a couple of points from your code.
1. Using "cmd /c python.exe code.py". In my code I just start
"python.exe code.py". However, I did notice that if I wait a bit the
GetExitCodeProcess would not return STILL_ACTIVE.
2. get_cancel_text() just returns a flag that was set when user
pressed a button on GUI.
3. You use temporary files instead of pipes. I'll try that.

I did try using _popen() before. But for some reason it didn't work.
It didn't get stuck, just exist right away.
Perhaps that note on MSDN site might cause this problem.
From: Hector Santos on 3 Mar 2010 03:40
IlyaK wrote:

> Hi Hector:
>
> I'll a couple of points from your code.
> 1. Using "cmd /c python.exe code.py". In my code I just start
> "python.exe code.py". However, I did notice that if I wait a bit the
> GetExitCodeProcess would not return STILL_ACTIVE.
> 2. get_cancel_text() just returns a flag that was set when user
> pressed a button on GUI.
> 3. You use temporary files instead of pipes. I'll try that.
>
> I did try using _popen() before. But for some reason it didn't work.
> It didn't get stuck, just exist right away.
> Perhaps that note on MSDN site might cause this problem.


Can you show your get_cancel_test()?

The loop you have does not loo correct. You need to do it in a manner
similar or close to what I showed it. The way you have it can
potentially allow a block read which may be because of the compiler
optimizing the loop.

Try this:

for (;;)
{
if (get_cancel_test() == true) break;
if (WaitForSingleObject(hChildProc, 0) == WAIT_OBJECT_0) break;
if (!GetExitCodeProcess(hChildProc, &lErrors) ||
lErrors != STILL_ACTIVE) break;

if ( (numRead = pipe_read( hChildStdOut,
readBuffer,iBufferSize )) > 0 ) {
printf("Log: %s\n", readBuffer);
} else {
break;
}
}

--
hls



--
HLS
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: How are Windows Connected to Processes?
Next: Apple Sues the HTC (Android phone maker) with Patents that effectsus all