Problem with pipe inheritance...

[Stephan Vermeire (Brutus)]

Hi,

This is my first post in this forum, I am hoping that someone can help me with the next problem.

Currently I am working on i/o multhithreading for Brutus. The GUI starts the first instance of Brutus which communicates fine with the GUI (winboard). Brutus starts another process which does the actual thinking and prints the resulting move to stdout.

When I start Brutus as a console, everything works fine. Under Arena as well: no problems. Under winboard however, the thinkingprocess isn't printing anything visibly!

I guess it has something to do with inheritace of the pipe handle. How can I do that? I have tried the following (which didn't work):

Code: Select all

STARTUPINFO si;
memset(& si, 0, sizeof(si));
si.cb = sizeof(STARTUPINFO);

si.dwFlags = STARTF_USESHOWWINDOW|STARTF_USESTDHANDLES;
si.hStdOutput=stdout;

...followed by....

CreateProcess(NULL, newName, NULL, NULL, TRUE, 0, 0, NULL, & si, & pi)

Now, the thinking-process doesn't show any input in the console either! What am I doing wrong here?

Hoping for a good suggestion, best wishes,
Stephan

[bob]

Hi,

This is my first post in this forum, I am hoping that someone can help me with the next problem.

Currently I am working on i/o multhithreading for Brutus. The GUI starts the first instance of Brutus which communicates fine with the GUI (winboard). Brutus starts another process which does the actual thinking and prints the resulting move to stdout.

When I start Brutus as a console, everything works fine. Under Arena as well: no problems. Under winboard however, the thinkingprocess isn't printing anything visibly!

I guess it has something to do with inheritace of the pipe handle. How can I do that? I have tried the following (which didn't work):

Code: Select all

STARTUPINFO si;
memset(& si, 0, sizeof(si));
si.cb = sizeof(STARTUPINFO);

si.dwFlags = STARTF_USESHOWWINDOW|STARTF_USESTDHANDLES;
si.hStdOutput=stdout;

...followed by....

CreateProcess(NULL, newName, NULL, NULL, TRUE, 0, 0, NULL, & si, & pi)

Now, the thinking-process doesn't show any input in the console either! What am I doing wrong here?

Hoping for a good suggestion, best wishes,
Stephan

Under unix there is no problem here, so you probably need to look for programming issues you have missed. When you create a new process, everything is shared between the parent and child, including any open descriptors. The only rule you need to satisfy is that both parent and child must not read from the _same_ pipe. This introduces a race condition that needs to be avoided at all cost. writes to stdout from multiple processes works just fine, although the output can be mangled with respect to order.

What is the "CreateProcess()" about? It is possible that you are using something that does odd things. It is not clear whether this is based on the normal fork() or on posix threads, since you have some sort of wrapper that hides the details.

[hgm]

It is a Windows API call. I don't think they know the word POSIX at MicroSoft...

[Stephan Vermeire (Brutus)]

Under unix there is no problem here, so you probably need to look for programming issues you have missed. When you create a new process, everything is shared between the parent and child, including any open descriptors. The only rule you need to satisfy is that both parent and child must not read from the _same_ pipe. This introduces a race condition that needs to be avoided at all cost. writes to stdout from multiple processes works just fine, although the output can be mangled with respect to order.

What is the "CreateProcess()" about? It is possible that you are using something that does odd things. It is not clear whether this is based on the normal fork() or on posix threads, since you have some sort of wrapper that hides the details.

Thanx for your quick repy!

The program is windows based, it is I suppose an API-problem. (Harm Geert is correct on this one). There are no processes reading from the same pipe, that would give serious problems indeed and has been avoided. The simultanuous printing is regulated by a mutex. As a console, all this works fine.

The trouble begins when I try to specify the stdout for the child process.
For some reason I am unable to feed the stdout from the parent to the child. It works only when I use specify no pipe at all, in that case the default for standard output is the console window's buffer. My guess is, winboard doesn't use this buffer and as a result all printing doesn't get through.

I think it is a specific windows problem.

[Gerd Isenberg]

Hi,
This is my first post in this forum, I am hoping that someone can help me with the next problem.

Now, the thinking-process doesn't show any input in the console either! What am I doing wrong here?

Hoping for a good suggestion, best wishes,
Stephan

Hi Stephan,
are you aware of this site? The topic seems related to your problem.
http://msdn.microsoft.com/en-us/library ... S.85).aspx

Cheers,
Gerd

[bob]

It is a Windows API call. I don't think they know the word POSIX at MicroSoft...

If he is running this under Unix, why is he using that I wonder???

[Stephan Vermeire (Brutus)]

Hi Stephan,
are you aware of this site? The topic seems related to your problem.
http://msdn.microsoft.com/en-us/library ... S.85).aspx

Cheers,
Gerd

That was exactly what I was looking for! I found the problem:

Code: Select all

si.hStdOutput=stdout

....must be:

si.hStdOutput=GetStdHandle(STD_OUTPUT_HANDLE);

Thanx a lot! You have been of great help!

Best wishes,
Stephan

[Gerd Isenberg]

That was exactly what I was looking for! I found the problem:

Code: Select all

si.hStdOutput=stdout

....must be:

si.hStdOutput=GetStdHandle(STD_OUTPUT_HANDLE);

Some luck with Google.

MS Handles seem not that typesafe that one can assign a FILE*