pid problem found

pid problem found

[jmm]

Ok, this may still be a B20.1 problem, but I'm definitely more shaky
about it now.  It turns out that after CreateProcess, the returned
PROCESS_INFORMATION structure has a dwProcessId entry that's usally
between 3 to 5 times the value of the real pid.

for instance, the spawned child's real PID will be 1070, but 
the dwProcessId will give 3919... the next run, real PID is 1072, 
but dwProcessId gives 4663, a third time real is 1075, dwProcessId
returns 3033.

(I've been using dwProcessId to save the pid for later waitpid() calls,
which now explains why those were failing)

I'm sorry to send to the list so much, but I've tried dejanews, web
searches, irc channels, NT programming books and have gotten stuck :(

Thanks for your help and patience,

James Manning
-- 
Hardware Design Engineer --- IBM Netfinity Performance Development

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[Christopher Faylor]

On Sun, Feb 07, 1999 at 10:27:07PM -0500, jmm@raleigh.ibm.com wrote:
>Ok, this may still be a B20.1 problem, but I'm definitely more shaky
>about it now.  It turns out that after CreateProcess, the returned
>PROCESS_INFORMATION structure has a dwProcessId entry that's usally
>between 3 to 5 times the value of the real pid.

There is absolutely no relationship between the dwProcessId returned by
CreateProcess and a cygwin pid.  Cygwin pids are generated by the DLL.

We can't use the Windows pid because Windows doesn't support anything
like the exec() function.  So, we have to enforce our own pids
independently of Windows.

If you want to use cygwin functions to wait for pids you'll have to use
cygwin functions to create processes as well.

>for instance, the spawned child's real PID will be 1070, but 
>the dwProcessId will give 3919... the next run, real PID is 1072, 
>but dwProcessId gives 4663, a third time real is 1075, dwProcessId
>returns 3033.
>
>(I've been using dwProcessId to save the pid for later waitpid() calls,
>which now explains why those were failing)

-- 
cgf@cygnus.com
http://www.cygnus.com/

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[John Mullee]

> PROCESS_INFORMATION structure has a dwProcessId entry that's usally
> between 3 to 5 times the value of the real pid.

This sounds very wierd.

The createprcess documentation says that the PID returned
is valid until the process ends;
it also says that the dwCreation flags can be ORed with
CREATE_NEW_CONSOLE and CREATE_NEW_PROCESS_GROUP, and that
the resulting pid can be used with OpenProcess.

Would it be possible that this 'pid' is something other
than that id seen in taskmanager? does cygwin's
waitpid use the CreateProcess-pid? or something else?

Could you send me the relevant source?
Are you running W95/98, or NT?

John

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[jmm]

> Would it be possible that this 'pid' is something other
> than that id seen in taskmanager? does cygwin's
> waitpid use the CreateProcess-pid? or something else?

That was it, as it turns out... CreateProcess returns a Windows pid,
not a cygwin pid, so cygwin1.dll's waitpid couldn't use it...

Unfortunately, I was using CreateProcess to do anonymous pipe inheritance
so each of the children could feed back an integer after getting a
SIGALRM and exit.

What this means now is that I'm stuck either converting the signal(),
alarm(), and waitpid() stuff to Win32 calls (events I guess) or trying
to dump all the anon pipe stuff in favor of some other IPC mechanism
(most likely moving to the Win32 event stuff, I'd guess, though all the
examples that I've seen do explicit checks for incoming messages in the
code and not something as simple as installing a handler to print one
integer and exit.

Thanks for all your help,

James Manning
-- 
Hardware Design Engineer --- IBM Netfinity Performance Development

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[Christopher Faylor]

On Mon, Feb 08, 1999 at 09:30:55AM -0500, jmm@raleigh.ibm.com wrote:
>> Would it be possible that this 'pid' is something other
>> than that id seen in taskmanager? does cygwin's
>> waitpid use the CreateProcess-pid? or something else?
>
>That was it, as it turns out... CreateProcess returns a Windows pid,
>not a cygwin pid, so cygwin1.dll's waitpid couldn't use it...
>
>Unfortunately, I was using CreateProcess to do anonymous pipe inheritance
>so each of the children could feed back an integer after getting a
>SIGALRM and exit.
>
>What this means now is that I'm stuck either converting the signal(),
>alarm(), and waitpid() stuff to Win32 calls (events I guess) or trying
>to dump all the anon pipe stuff in favor of some other IPC mechanism
>(most likely moving to the Win32 event stuff, I'd guess, though all the
>examples that I've seen do explicit checks for incoming messages in the
>code and not something as simple as installing a handler to print one
>integer and exit.

Umm.  Cygwin supports anonymous pipes.  Think UNIX.  That's what we're
trying to emulate.

cgf

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[jmm]

> Umm.  Cygwin supports anonymous pipes.  Think UNIX.  That's what we're
> trying to emulate.

True enough... I should have said "Anon pipes created with CreatePipe
and DuplicateHandle and inherited through CreateProcess"... unless
I can swap out CreateProcess and the other stuff works (not saying
that's not the case, just can't find an API call that claims to do
this), then it's code re-write either way, and I might as well move
the signal handling stuff over to events since that's pretty small
code already (like I said, print an int and exit :)

Thanks again,

James

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[John Mullee]

> (most likely moving to the Win32 event stuff, I'd guess, though all the
> examples that I've seen do explicit checks for incoming messages in the
> code and not something as simple as installing a handler to print one
> integer and exit.

have a look at the WaitForSingleObject and WaitForMultipleObjects api
calls.
The can accept, among other handles, event handles:
  CreateEvent OpenEvent SetEvent PulseEvent ResetEvent CloseHandle
as well as process, thread, semephore, mutex, conio and various
file-change 
system message handles.
If you'd _really_ prefer to have wrappers that isolate you from all the
OS
dependant low-level bits, think about visiting ACE at:
http://www.cs.wustl.edu/~schmidt/ or news://comp.soft-sys.ace

BTW wow, the new maillist software! realtime!

john

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[Christopher Faylor]

On Mon, Feb 08, 1999 at 09:43:23AM -0500, jmm@raleigh.ibm.com wrote:
>> Umm.  Cygwin supports anonymous pipes.  Think UNIX.  That's what we're
>> trying to emulate.
>
>True enough... I should have said "Anon pipes created with CreatePipe
>and DuplicateHandle and inherited through CreateProcess"... unless
>I can swap out CreateProcess and the other stuff works (not saying
>that's not the case, just can't find an API call that claims to do
>this), then it's code re-write either way, and I might as well move
>the signal handling stuff over to events since that's pretty small
>code already (like I said, print an int and exit :)

Cygwin pipes are created with CreatePipe.  These pipes can be duplicated
with dup() or dup2().  They follow UNIX inheritance rules, i.e., they're
inherited by subprocesses by default.

That means that pipes will be inherited by processes that are
fork/execed or spawned.

Somehow I still get the feeling that you're making this a lot more
complicated than is warranted.

cgf

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[jmm]

> Somehow I still get the feeling that you're making this a lot more
> complicated than is warranted.

You're probably right, so let me throw out what I'm trying to do and
get a knowledgable answer :)

Program started out as just running and spawning x children, but run time
was variable and we need to be able to either pass a "seconds to run"
param or stop it with an event/signal (specifically, from a perl script
that runs the parent process).  When signaled, the children will need
to feed back one integer (for loop index, kept as a global var in each
child) and exit.

Approach was going to be have perl kill -ALRM the parent, have it handle
and cascade the ALRM to children, read the integers from the pipes that
were inherited by the children, and print some stats. (each child would
handle ALRM by printf'ing the int and exit'ing)

The code has to eventually be able to compile and run on just MS VC++
(not my choice) w/o the cygwin dll, but I was hoping to use the cygwin
stuff to just get it up and working and migrate over to pure Win32 after
the fact (once the immediate need for something that works is done)

Thanks again for all your help and patience,

James Manning
-- 
Hardware Design Engineer --- IBM Netfinity Performance Development

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[Christopher Faylor]

On Mon, Feb 08, 1999 at 09:59:49AM -0500, jmm@raleigh.ibm.com wrote:
>> Somehow I still get the feeling that you're making this a lot more
>> complicated than is warranted.
>
>You're probably right, so let me throw out what I'm trying to do and
>get a knowledgable answer :)
>
>Program started out as just running and spawning x children, but run time
>was variable and we need to be able to either pass a "seconds to run"
>param or stop it with an event/signal (specifically, from a perl script
>that runs the parent process).  When signaled, the children will need
>to feed back one integer (for loop index, kept as a global var in each
>child) and exit.
>
>Approach was going to be have perl kill -ALRM the parent, have it handle
>and cascade the ALRM to children, read the integers from the pipes that
>were inherited by the children, and print some stats. (each child would
>handle ALRM by printf'ing the int and exit'ing)
>
>The code has to eventually be able to compile and run on just MS VC++
>(not my choice) w/o the cygwin dll, but I was hoping to use the cygwin
>stuff to just get it up and working and migrate over to pure Win32 after
>the fact (once the immediate need for something that works is done)

All of this is easily doable with cygwin using UNIX functions, as I've
indicated.  You will need a cygwin perl, though.

Otherwise, I don't believe that the above scenario won't work in a
Windows environment.  There is no equivalent to SIGALRM under standard
Windows.  There are probably other methods that you could use to accomplish
the same thing, though, like waiting for an event in a separate thread.

cgf



--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[jmm]

> Umm.  Cygwin supports anonymous pipes.  Think UNIX.  That's what we're
> trying to emulate.

True enough... I should have said "Anon pipes created with CreatePipe
and DuplicateHandle and inherited through CreateProcess"... unless
I can swap out CreateProcess and the other stuff works (not saying
that's not the case, just can't find an API call that claims to do
this), then it's code re-write either way, and I might as well move
the signal handling stuff over to events since that's pretty small
code already (like I said, print an int and exit :)

Thanks again,

James

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[jmm]

> Somehow I still get the feeling that you're making this a lot more
> complicated than is warranted.

You're probably right, so let me throw out what I'm trying to do and
get a knowledgable answer :)

Program started out as just running and spawning x children, but run time
was variable and we need to be able to either pass a "seconds to run"
param or stop it with an event/signal (specifically, from a perl script
that runs the parent process).  When signaled, the children will need
to feed back one integer (for loop index, kept as a global var in each
child) and exit.

Approach was going to be have perl kill -ALRM the parent, have it handle
and cascade the ALRM to children, read the integers from the pipes that
were inherited by the children, and print some stats. (each child would
handle ALRM by printf'ing the int and exit'ing)

The code has to eventually be able to compile and run on just MS VC++
(not my choice) w/o the cygwin dll, but I was hoping to use the cygwin
stuff to just get it up and working and migrate over to pure Win32 after
the fact (once the immediate need for something that works is done)

Thanks again for all your help and patience,

James Manning
-- 
Hardware Design Engineer --- IBM Netfinity Performance Development

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[Christopher Faylor]

On Mon, Feb 08, 1999 at 09:30:55AM -0500, jmm@raleigh.ibm.com wrote:
>> Would it be possible that this 'pid' is something other
>> than that id seen in taskmanager? does cygwin's
>> waitpid use the CreateProcess-pid? or something else?
>
>That was it, as it turns out... CreateProcess returns a Windows pid,
>not a cygwin pid, so cygwin1.dll's waitpid couldn't use it...
>
>Unfortunately, I was using CreateProcess to do anonymous pipe inheritance
>so each of the children could feed back an integer after getting a
>SIGALRM and exit.
>
>What this means now is that I'm stuck either converting the signal(),
>alarm(), and waitpid() stuff to Win32 calls (events I guess) or trying
>to dump all the anon pipe stuff in favor of some other IPC mechanism
>(most likely moving to the Win32 event stuff, I'd guess, though all the
>examples that I've seen do explicit checks for incoming messages in the
>code and not something as simple as installing a handler to print one
>integer and exit.

Umm.  Cygwin supports anonymous pipes.  Think UNIX.  That's what we're
trying to emulate.

cgf

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[Christopher Faylor]

On Mon, Feb 08, 1999 at 09:43:23AM -0500, jmm@raleigh.ibm.com wrote:
>> Umm.  Cygwin supports anonymous pipes.  Think UNIX.  That's what we're
>> trying to emulate.
>
>True enough... I should have said "Anon pipes created with CreatePipe
>and DuplicateHandle and inherited through CreateProcess"... unless
>I can swap out CreateProcess and the other stuff works (not saying
>that's not the case, just can't find an API call that claims to do
>this), then it's code re-write either way, and I might as well move
>the signal handling stuff over to events since that's pretty small
>code already (like I said, print an int and exit :)

Cygwin pipes are created with CreatePipe.  These pipes can be duplicated
with dup() or dup2().  They follow UNIX inheritance rules, i.e., they're
inherited by subprocesses by default.

That means that pipes will be inherited by processes that are
fork/execed or spawned.

Somehow I still get the feeling that you're making this a lot more
complicated than is warranted.

cgf

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[John Mullee]

> (most likely moving to the Win32 event stuff, I'd guess, though all the
> examples that I've seen do explicit checks for incoming messages in the
> code and not something as simple as installing a handler to print one
> integer and exit.

have a look at the WaitForSingleObject and WaitForMultipleObjects api
calls.
The can accept, among other handles, event handles:
  CreateEvent OpenEvent SetEvent PulseEvent ResetEvent CloseHandle
as well as process, thread, semephore, mutex, conio and various
file-change 
system message handles.
If you'd _really_ prefer to have wrappers that isolate you from all the
OS
dependant low-level bits, think about visiting ACE at:
http://www.cs.wustl.edu/~schmidt/ or news://comp.soft-sys.ace

BTW wow, the new maillist software! realtime!

john

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[Christopher Faylor]

On Sun, Feb 07, 1999 at 10:27:07PM -0500, jmm@raleigh.ibm.com wrote:
>Ok, this may still be a B20.1 problem, but I'm definitely more shaky
>about it now.  It turns out that after CreateProcess, the returned
>PROCESS_INFORMATION structure has a dwProcessId entry that's usally
>between 3 to 5 times the value of the real pid.

There is absolutely no relationship between the dwProcessId returned by
CreateProcess and a cygwin pid.  Cygwin pids are generated by the DLL.

We can't use the Windows pid because Windows doesn't support anything
like the exec() function.  So, we have to enforce our own pids
independently of Windows.

If you want to use cygwin functions to wait for pids you'll have to use
cygwin functions to create processes as well.

>for instance, the spawned child's real PID will be 1070, but 
>the dwProcessId will give 3919... the next run, real PID is 1072, 
>but dwProcessId gives 4663, a third time real is 1075, dwProcessId
>returns 3033.
>
>(I've been using dwProcessId to save the pid for later waitpid() calls,
>which now explains why those were failing)

-- 
cgf@cygnus.com
http://www.cygnus.com/

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[Christopher Faylor]

On Mon, Feb 08, 1999 at 09:59:49AM -0500, jmm@raleigh.ibm.com wrote:
>> Somehow I still get the feeling that you're making this a lot more
>> complicated than is warranted.
>
>You're probably right, so let me throw out what I'm trying to do and
>get a knowledgable answer :)
>
>Program started out as just running and spawning x children, but run time
>was variable and we need to be able to either pass a "seconds to run"
>param or stop it with an event/signal (specifically, from a perl script
>that runs the parent process).  When signaled, the children will need
>to feed back one integer (for loop index, kept as a global var in each
>child) and exit.
>
>Approach was going to be have perl kill -ALRM the parent, have it handle
>and cascade the ALRM to children, read the integers from the pipes that
>were inherited by the children, and print some stats. (each child would
>handle ALRM by printf'ing the int and exit'ing)
>
>The code has to eventually be able to compile and run on just MS VC++
>(not my choice) w/o the cygwin dll, but I was hoping to use the cygwin
>stuff to just get it up and working and migrate over to pure Win32 after
>the fact (once the immediate need for something that works is done)

All of this is easily doable with cygwin using UNIX functions, as I've
indicated.  You will need a cygwin perl, though.

Otherwise, I don't believe that the above scenario won't work in a
Windows environment.  There is no equivalent to SIGALRM under standard
Windows.  There are probably other methods that you could use to accomplish
the same thing, though, like waiting for an event in a separate thread.

cgf



--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[jmm]

> Would it be possible that this 'pid' is something other
> than that id seen in taskmanager? does cygwin's
> waitpid use the CreateProcess-pid? or something else?

That was it, as it turns out... CreateProcess returns a Windows pid,
not a cygwin pid, so cygwin1.dll's waitpid couldn't use it...

Unfortunately, I was using CreateProcess to do anonymous pipe inheritance
so each of the children could feed back an integer after getting a
SIGALRM and exit.

What this means now is that I'm stuck either converting the signal(),
alarm(), and waitpid() stuff to Win32 calls (events I guess) or trying
to dump all the anon pipe stuff in favor of some other IPC mechanism
(most likely moving to the Win32 event stuff, I'd guess, though all the
examples that I've seen do explicit checks for incoming messages in the
code and not something as simple as installing a handler to print one
integer and exit.

Thanks for all your help,

James Manning
-- 
Hardware Design Engineer --- IBM Netfinity Performance Development

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

pid problem found

[jmm]

Ok, this may still be a B20.1 problem, but I'm definitely more shaky
about it now.  It turns out that after CreateProcess, the returned
PROCESS_INFORMATION structure has a dwProcessId entry that's usally
between 3 to 5 times the value of the real pid.

for instance, the spawned child's real PID will be 1070, but 
the dwProcessId will give 3919... the next run, real PID is 1072, 
but dwProcessId gives 4663, a third time real is 1075, dwProcessId
returns 3033.

(I've been using dwProcessId to save the pid for later waitpid() calls,
which now explains why those were failing)

I'm sorry to send to the list so much, but I've tried dejanews, web
searches, irc channels, NT programming books and have gotten stuck :(

Thanks for your help and patience,

James Manning
-- 
Hardware Design Engineer --- IBM Netfinity Performance Development

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: pid problem found

[John Mullee]

> PROCESS_INFORMATION structure has a dwProcessId entry that's usally
> between 3 to 5 times the value of the real pid.

This sounds very wierd.

The createprcess documentation says that the PID returned
is valid until the process ends;
it also says that the dwCreation flags can be ORed with
CREATE_NEW_CONSOLE and CREATE_NEW_PROCESS_GROUP, and that
the resulting pid can be used with OpenProcess.

Would it be possible that this 'pid' is something other
than that id seen in taskmanager? does cygwin's
waitpid use the CreateProcess-pid? or something else?

Could you send me the relevant source?
Are you running W95/98, or NT?

John

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe@sourceware.cygnus.com