Board index » cppbuilder » Named pipe conundrum

Named pipe conundrum


2006-02-01 01:57:24 AM
cppbuilder93
Greetings all,
I'm trying to debug a recalcitrant C++Builder 6 app and had the brainstorm of writing a separate pipe server task to receive/ log-to-file debug messages from it. Both programs would reside on the same machine. I've tested the pipe server with a small console based client app that successfully writes large amounts of data, FAST. All appears fine on the server side. (The server app is written in the "old-fashioned" WIN32 manner, as I'm that kind of guy.)
I blithely thought that incorporating the client side into the buggy app would be a snap, but... I can only perform a single write into the pipe, using WriteFile(...) before it seems that I never get another I/O event signalling that the write was finished and the API is ready for another message.
Here's what the client send routine looks like...the setup of the OVERLAPPED struct and creation of the event and existing pipe file are done elsewhere. I tried to duplicate the logic of the test client.
void TMyAppForm::WriteToPipe(char *pC)
{
unsigned long BytesWritten;
while(WaitForSingleObject(io.hEvent, 0) == WAIT_TIMEOUT)
Application->ProcessMessages();
ResetEvent(io.hEvent);
if(!WriteFile(hPipe, pC, strlen(pC), &BytesWritten, &io))
{
while(GetLastError() == ERROR_IO_PENDING)
Application->ProcessMessages();
}
}
Note that I'm a newbie to pipe IPC and am more familiar with M$ compiler environments.
Could the main message handler be "eating" my io events? I'm stumped.
Thanks for any and all help,
Duane
 
 

Re:Named pipe conundrum

"Duane A." < XXXX@XXXXX.COM >wrote in message
Quote
I'm trying to debug a recalcitrant C++Builder 6 app and had the
brainstorm of writing a separate pipe server task to receive/
log-to-file debug messages from it. Both programs would reside
on the same machine.
An easier thing to do is to use the OutputDebugString() function instead.
You can then use a third-party viewer, such as DebugView from
www.sysinternals.com.
Quote
I blithely thought that incorporating the client side into the buggy
app would be a snap, but... I can only perform a single write into
the pipe, using WriteFile(...) before it seems that I never get another
I/O event signalling that the write was finished and the API is ready
for another message.
After you call WriteFile(), DO NOT call GetLastError() in a loop! Calling
ProcessMessages() can change the value that GetLastError() returns (since
ProcessMessage() calls other API functons internally), and that value will
have nothing to do with the I/O operation at all. Also, using
GetLastError() to wait for an I/O operation to complete is the completely
wrong approach to take anyway. If you take out the ProcessMessages() then
GetLastError() would not change value at all, so you would end up in an
endlesss loop.
Call GetLastError() ONCE and then use WaitForSingleObject() or
GetOverlappedResult() to perform the waiting.
Alternatively, get rid of the overlapped I/O altogether. Then WriteFile()
will not return until the full data has been written (or an error occurs).
Gambit