Verify a pipe is "alive".

I'm working on a project (SourceForge, AMaMP) that involves using pipes for communication. Currently, the connection is checked to see if it's alive by taking a peek (PeekNamedPipe) at it. I was under the impression that if it wasn't connected, checking it should return 0 and GetLastError should return 109 (The pipe has been ended). If there's data in it, it seemed that it wouldn't return 0. So I drain the pipe by reading (ReadFile) all the data from it and then peeking at it again. The return value is not 0 all the time so for some reason, even though the program at the other end has ended, the code insists that the pipe is still valid.

In short, I want a method of verifying that the connection is still alive, perhaps some way of validating the handle to the pipe?

Thanks,
KDL

Comments

  • [b][red]This message was edited by kel1981b at 2004-5-20 11:10:13[/red][/b][hr]
    [b][red]This message was edited by kel1981b at 2004-5-20 11:9:53[/red][/b][hr]
    : I'm working on a project (SourceForge, AMaMP) that involves using pipes for communication. Currently, the connection is checked to see if it's alive by taking a peek (PeekNamedPipe) at it. I was under the impression that if it wasn't connected, checking it should return 0 and GetLastError should return 109 (The pipe has been ended). If there's data in it, it seemed that it wouldn't return 0. So I drain the pipe by reading (ReadFile) all the data from it and then peeking at it again. The return value is not 0 all the time so for some reason, even though the program at the other end has ended, the code insists that the pipe is still valid.
    :
    : In short, I want a method of verifying that the connection is still alive, perhaps some way of validating the handle to the pipe?
    :
    : Thanks,
    : KDL
    :
    I think you need to use ReadFileEx instead of ReadFile. Try this link.
    http://oldlook.experts-exchange.com:8080/Programming/Programming_Languages/Visual_Basic/Q_20934771.html
    Just cut and paste this link to the address. For some reason it did not fit PH textbox


  • : I think you need to use ReadFileEx instead of ReadFile. Try this link.
    :

    That would do the job of PeekNamedPipe and ReadFile but I don't think it would do the trick. If PeekNamedPipe and ReadFile both still think the handle is valid when it shouldn't be, then ReadFileEx probably will as well. I think I found an alternate solution though in simply checking the processID to see if the app is still running...

    : Just cut and paste this link to the address. For some reason it did not fit PH textbox
    :

    It fit, but the script breaks on the ":" and thinks the URL is done.

    Thanks!

  • : That would do the job of PeekNamedPipe and ReadFile but I don't think it would do the trick. If PeekNamedPipe and ReadFile both still think the handle is valid when it shouldn't be, then ReadFileEx probably will as well.
    [blue]

    I would agree on this. If one API doesnt retuns the original status
    then probably the other will not. But its worth trying once KDL.

    PS. Have you got my mail KDL ???

    [/blue]


    :I think I found an alternate solution though in simply checking the processID to see if the app is still running...

    [/blue]

    Good thought KDL. It will definately do the trick.

    I was just wondering that this processID is generated differently
    every time we start the program or is constant for a particular Application ?

    And what about Process ID's of different versions running of same Application ????

    Is processID somehow related to the caption of the parent windows ????

    [/blue]


    [b]Regards
    Er. [blue]Gurpreet Singh [/blue](B.E [blue]Mech.)[/blue][/b]
    [hr]



  • : PS. Have you got my mail KDL ???

    Yes.

    : I was just wondering that this processID is generated differently
    : every time we start the program or is constant for a particular Application ?
    :
    : And what about Process ID's of different versions running of same Application ????
    :
    : Is processID somehow related to the caption of the parent windows ????

    A new processID is generated every time you start a process. It might be random but it is unique on that system. It's how Windows keeps track of processes.
  • Just a gap filler for the interested...

    : : I was just wondering that this processID is generated differently
    : : every time we start the program or is constant for a particular Application ?
    : :
    : : And what about Process ID's of different versions running of same Application ????
    : :
    : : Is processID somehow related to the caption of the parent windows ????
    :
    : A new processID is generated every time you start a process. It might be random but it is unique on that system. It's how Windows keeps track of processes.
    :
    That's right. The big thing to remember with processes is that a process is not the same as program. A program is just a bunch of bytes that represent instructions to the processor. A process on the other hand is the "instantiation" of a program - a bit like in OOP where the class contains your code, then an object is an instantiation of that code. Also, a process isn't just a copy of the program in memory being executed - it has the context of the program to (e.g. program counter, stack base, page table, registers...)

    On Win32 you create a new process using the CreateProcess system call. You give it the name of the executable that you want to create the process from. It sets up the process and, like KDL says, gives it a unique ID - this turns out to be a numerical ID on every OS I've ever studied.

    On UNIX things are different. A process can fork() another process, which basically clones the current process. If you then want that procoess to become another program, you use another system call (execve usually). However, you can also do this to make your own program concurrent. The upshot of all of this is that in UNIX every process has a parent, and usually if the parent terminates so does the child (parents are exepcted to reap their kids, otherwise they become zombies - yeah, I know, UNIX has better terminology than Win32... ;-)).

    If you want to have multiple copies of one program running, they will each have a different process ID. As a memory-saving optimisation, the operating system may actually only load one copy of the program's executable code into memory and map other processes to that same code. This is done with DLLs too - so they only need to be loaded into memory once even if many programs use them.

    OK, that's my operating systems exam revision for the day. :-)

    Jonathan

    ###
    for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
    (tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
    /(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories