Visual Basic

Moderators: None (Apply to moderate this forum)
Number of threads: 18011
Number of posts: 55384

This Forum Only
Post New Thread
Single Post View       Linear View       Threaded View      f

Report
Verify a pipe is "alive". Posted by KDivad Leahcim on 19 May 2004 at 8:29 PM
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
Report
Re: Verify a pipe is "alive". Posted by kel1981b on 20 May 2004 at 11:06 AM
This message was edited by kel1981b at 2004-5-20 11:10:13

This message was edited by kel1981b at 2004-5-20 11:9:53

: 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


Report
Re: Verify a pipe is "alive". Posted by KDivad Leahcim on 20 May 2004 at 9:40 PM
: 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!
Report
Re: Verify a pipe is "alive". Posted by Gurpreet2311 on 21 May 2004 at 8:57 AM

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




: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]


Regards
Er. Gurpreet Singh (B.E Mech.)






Report
Re: Verify a pipe is "alive". Posted by KDivad Leahcim on 21 May 2004 at 5:29 PM
: 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.
Report
Re: Verify a pipe is "alive". Posted by Jonathan on 22 May 2004 at 3:16 AM
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.");




 

Recent Jobs

Official Programmer's Heaven Blogs
Web Hosting | Browser and Social Games | Gadgets

Popular resources on Programmersheaven.com
Assembly | Basic | C | C# | C++ | Delphi | Flash | Java | JavaScript | Pascal | Perl | PHP | Python | Ruby | Visual Basic
© Copyright 2011 Programmersheaven.com - All rights reserved.
Reproduction in whole or in part, in any form or medium without express written permission is prohibited.
Violators of this policy may be subject to legal action. Please read our Terms Of Use and Privacy Statement for more information.
Operated by CommunityHeaven, a BootstrapLabs company.