RE: Extending cygwin's process table

RE: Extending cygwin's process table

[Robert Collins]

Chris,
	sounds good, If ps can give the start time for a process then it
won't cause any grief for me. If there is no way for me to tell the
order processes are launched in though, that could be difficult.

Rob

-----Original Message-----
From: Chris Faylor [ mailto:cgf@cygnus.com ]
Sent: Wednesday, 19 July 2000 1:43 PM
To: cygwin@sourceware.cygnus.com
Subject: Extending cygwin's process table


I am planning on revamping cygwin's process table for version 1.1.4.
I hope to make process creation a little faster and to also allow many
more cygwin processes.

I'm also toying with trying to more closely tie cygwin pids to windows
pids.

Is anyone going to be bothered if pid creation is not monotonic?  By
that I mean, parent pid 1000 may not create child pid 1001.  It may
create child pid 27.

It may still not be feasible to use cygwin pids as windows pids
(possibly because I don't believe that pid 1 is special to windows) but
I thought I'd give this a try anyway unless there is something that I'm
missing.

cgf

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


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

Re: Extending cygwin's process table

[Chris Faylor]

On Wed, Jul 19, 2000 at 03:30:10PM +1000, Robert Collins wrote:
>	sounds good, If ps can give the start time for a process then it
>won't cause any grief for me. If there is no way for me to tell the
>order processes are launched in though, that could be difficult.

Yes.  The start time is stored now and I would not remove this.  I could
add an option to ps to sort the processes by start time, too.

I didn't make it clear that the reason that the pids would look like this
is that Windows is very random in its pid assignment.

cgf

>-----Original Message-----
>From: Chris Faylor [ mailto:cgf@cygnus.com ]
>Sent: Wednesday, 19 July 2000 1:43 PM
>To: cygwin@sourceware.cygnus.com
>Subject: Extending cygwin's process table
>
>
>I am planning on revamping cygwin's process table for version 1.1.4.
>I hope to make process creation a little faster and to also allow many
>more cygwin processes.
>
>I'm also toying with trying to more closely tie cygwin pids to windows
>pids.
>
>Is anyone going to be bothered if pid creation is not monotonic?  By
>that I mean, parent pid 1000 may not create child pid 1001.  It may
>create child pid 27.
>
>It may still not be feasible to use cygwin pids as windows pids
>(possibly because I don't believe that pid 1 is special to windows) but
>I thought I'd give this a try anyway unless there is something that I'm
>missing.
>
>cgf
>
>--
>Want to unsubscribe from this list?
>Send a message to cygwin-unsubscribe@sourceware.cygnus.com
>
>
>--
>Want to unsubscribe from this list?
>Send a message to cygwin-unsubscribe@sourceware.cygnus.com

-- 
cgf@cygnus.com                        Cygnus Solutions, a Red Hat company
http://sourceware.cygnus.com/         http://www.redhat.com/

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

RE: Extending cygwin's process table

[Andrew Dalgleish]

> -----Original Message-----
> From:	Chris Faylor [SMTP:cgf@cygnus.com]
> Sent:	Thursday, July 20, 2000 04:22
> To:	cygwin@sources.redhat.com
> Subject:	Re: Extending cygwin's process table
> 
> On Wed, Jul 19, 2000 at 09:04:55AM -0400, Noel L Yap wrote:
> >cgf@cygnus.com on 2000.07.18 23:43:19
> >>I'm also toying with trying to more closely tie cygwin pids to
> windows
> >>pids.
> >
> >IMHO, this'd be great.
> >
> >>Is anyone going to be bothered if pid creation is not monotonic?  By
> >>that I mean, parent pid 1000 may not create child pid 1001.  It may
> >>create child pid 27.
> >
> >I don't think anything should be relying on this behaviour since it's
> not always
> >satisfied (ie when ppid is near the max pid allowed).
> 
> Yeah, I certainly know this.  I was just wondering if people would be
> shocked
> and outraged by any new "random" behavior.
[Andrew Dalgleish]  

I'd say mix 'em up, for two reasons:


1.
Some security conscious OSs generate random PIDs to prevent certain
types of attack.
Think about /tmp file predictions.
If you know process FOO has a PID of N, and its child creates a file
/tmp/son-of-foo.$$, you could create a symlink from
/tmp/son-of-foo.(N+1) to /etc/passwd.

2.
Unless you can guarantee that the cygwin PIDs are the same as windows
PIDs, I would suggest that you make them as different as possible to
discourage people from confusing the two.
If they are the same 99% of the time, some fool will think they are
*always* the same and come to rely on it.
Then you'll get posts of "but it works on NT".

Regards,
Andrew Dalgleish


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

RE: Extending cygwin's process table

[Heribert Dahms]

Hi Chris,

I don't bother.
I dunno if PID 1is special to NT, but my System process is currently 2,
FWIW.
In case of a problematic PID assigned, perhaps retry creating another
process first, then terminate the original?

Bye, Heribert (heribert_dahms@icon-gmbh.de)

> -----Original Message-----
> From:	Chris Faylor [SMTP:cgf@cygnus.com]
> Sent:	Wednesday, July 19, 2000 05:43
> To:	cygwin@sourceware.cygnus.com
> Subject:	Extending cygwin's process table
> 
> I am planning on revamping cygwin's process table for version 1.1.4.
> I hope to make process creation a little faster and to also allow many
> more cygwin processes.
> 
> I'm also toying with trying to more closely tie cygwin pids to windows
> pids.
> 
> Is anyone going to be bothered if pid creation is not monotonic?  By
> that I mean, parent pid 1000 may not create child pid 1001.  It may
> create child pid 27.
> 
> It may still not be feasible to use cygwin pids as windows pids
> (possibly because I don't believe that pid 1 is special to windows)
> but
> I thought I'd give this a try anyway unless there is something that
> I'm
> missing.
> 
> cgf
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

Re: Extending cygwin's process table

[Chris Faylor]

On Wed, Jul 19, 2000 at 02:24:27PM -0400, Chris Faylor wrote:
>I think it may be possible but cygwin pids could comprise up to two
>windows pids.  I'm still in thinking out load stage, though, despite
					  loud
>having thought about this problem for three years now.

cgf

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

Re: Extending cygwin's process table

[Chris Faylor]

On Wed, Jul 19, 2000 at 04:16:01PM +0100, Tony Arnold wrote:
>Chris,
>
>> >Does this mean we could get ps to report the Windows processes as well as
>> >the cygwin ones? Also for kill to work on Windows processes as well as
>> >cygwin ones, or is this asking too much?
>>
>> Nope.  I was going to investigate doing this, too.  I've had generic pid
>> walking code for a couple of years that I was going to "round tuit" into
>> cygwin but...
>
>OK. Just a suggestion that I think could prove very useful.

I'm not sure if my response was clear.  You said "is this asking too
much?" And I said "No", meaning "No, it's not too much to ask."

I had a goal of including non-cygwin pids in the ps output.

>> Btw, I should point out that it's not likely that I can get a
>> 100% correspondence
>> between windows pids and cygwin pids.  Instead, the pids will
>> have a likelihood
>> of being the same but no guarantee.
>
>I guess if you were going to implement my suggestion above, then there would
>be a requirement for cygwin PIDs and Windows PIDs to be unique accross the
>system, i.e., you could not have cygwin PID be the same number as a Windows
>PID.

I think it may be possible but cygwin pids could comprise up to two
windows pids.  I'm still in thinking out load stage, though, despite
having thought about this problem for three years now.

cgf

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

Re: Extending cygwin's process table

[Chris Faylor]

On Wed, Jul 19, 2000 at 09:04:55AM -0400, Noel L Yap wrote:
>cgf@cygnus.com on 2000.07.18 23:43:19
>>I'm also toying with trying to more closely tie cygwin pids to windows
>>pids.
>
>IMHO, this'd be great.
>
>>Is anyone going to be bothered if pid creation is not monotonic?  By
>>that I mean, parent pid 1000 may not create child pid 1001.  It may
>>create child pid 27.
>
>I don't think anything should be relying on this behaviour since it's not always
>satisfied (ie when ppid is near the max pid allowed).

Yeah, I certainly know this.  I was just wondering if people would be shocked
and outraged by any new "random" behavior.

cgf

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

RE: Extending cygwin's process table

[Tony Arnold]

Chris,

> >Does this mean we could get ps to report the Windows processes as well as
> >the cygwin ones? Also for kill to work on Windows processes as well as
> >cygwin ones, or is this asking too much?
>
> Nope.  I was going to investigate doing this, too.  I've had generic pid
> walking code for a couple of years that I was going to "round tuit" into
> cygwin but...

OK. Just a suggestion that I think could prove very useful.

> Btw, I should point out that it's not likely that I can get a
> 100% correspondence
> between windows pids and cygwin pids.  Instead, the pids will
> have a likelihood
> of being the same but no guarantee.

I guess if you were going to implement my suggestion above, then there would
be a requirement for cygwin PIDs and Windows PIDs to be unique accross the
system, i.e., you could not have cygwin PID be the same number as a Windows
PID.

Regards,
Tony.
--
Tony Arnold, Head of Science and Engineering Support Unit,
University of Manchester. Tel: +44 161 275 6093, Fax: +44 161 275 6071
E-mail: tony.arnold@man.ac.uk, Home: http://www.man.ac.uk/Tony.Arnold


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

Re: Extending cygwin's process table

[Chris Faylor]

On Wed, Jul 19, 2000 at 02:27:26PM +0100, Tony Arnold wrote:
>> I am planning on revamping cygwin's process table for version 1.1.4.
>> I hope to make process creation a little faster and to also allow many
>> more cygwin processes.
>>
>> I'm also toying with trying to more closely tie cygwin pids to windows
>> pids.
>
>Does this mean we could get ps to report the Windows processes as well as
>the cygwin ones? Also for kill to work on Windows processes as well as
>cygwin ones, or is this asking too much?

Nope.  I was going to investigate doing this, too.  I've had generic pid
walking code for a couple of years that I was going to "round tuit" into
cygwin but...

Btw, I should point out that it's not likely that I can get a 100% correspondence
between windows pids and cygwin pids.  Instead, the pids will have a likelihood
of being the same but no guarantee.

cgf

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

Re: Extending cygwin's process table

[Chris Faylor]

On Wed, Jul 19, 2000 at 09:45:54AM -0400, Andre Bleau wrote:
>Functions that map PIDs between Windows and Cygwin would be useful; e.g.,
>getWindowsPID(CygwinPID) and getCygwinPID(WindowsPID).

The analogue of those functions already exist in cygwin.

cgf

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

RE: Extending cygwin's process table

[Noel L Yap]

"Monotonic" means that a sequence moves in the same direction (or stays the
same).  It doesn't mean that it's sequential.  So, for example, the sequence
"100, 101, 103" is monotonic.

The reason pids are non-monotonic is 'cos they cycle.  Pids aren't unique
through time -- they're reused.

Noel




mark@npsl.co.uk on 2000.07.19 09:17:35

To:   yap_noel@jpmorgan.com, cygwin@sources.redhat.com
cc:
Subject:  RE: Extending cygwin's process table




Isn't pid creation inherently non-monotonic anyway due to multitasking
considerations, i.e.

1.   X w/pid 100 creates Y w/pid 101
2.   A w/pid 2 creates B w/pid 102
3.   Y w/pid 101 creates Z w/pid 103

...so anything that relies on monotonicity just won't be robust.  Just my
2p's worth!

Mark



-----Original Message-----
From: cygwin-owner@sources.redhat.com
[ mailto:cygwin-owner@sources.redhat.com]On Behalf Of Noel L Yap
Sent: Wednesday, July 19, 2000 2:05 PM
To: cygwin@sources.redhat.com
Subject: Re: Extending cygwin's process table






cgf@cygnus.com on 2000.07.18 23:43:19
>I'm also toying with trying to more closely tie cygwin pids to windows
>pids.

IMHO, this'd be great.

>Is anyone going to be bothered if pid creation is not monotonic?  By
>that I mean, parent pid 1000 may not create child pid 1001.  It may
>create child pid 27.

I don't think anything should be relying on this behaviour since it's not
always
satisfied (ie when ppid is near the max pid allowed).

>It may still not be feasible to use cygwin pids as windows pids
>(possibly because I don't believe that pid 1 is special to windows) but
>I thought I'd give this a try anyway unless there is something that I'm
>missing.

Yeah, I'm not sure if it's possible, but it's worth a shot (unless someone
out
there knows for sure that it's not possible).

Noel




This communication is for informational purposes only.  It is not intended
as
an offer or solicitation for the purchase or sale of any financial
instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.


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






This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.


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

Re: Extending cygwin's process table

[Andre Bleau]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

>I am planning on revamping cygwin's process table for version 1.1.4.
>I hope to make process creation a little faster and to also allow many
>more cygwin processes.
>
>I'm also toying with trying to more closely tie cygwin pids to windows
>pids.
>
>Is anyone going to be bothered if pid creation is not monotonic?  By
>that I mean, parent pid 1000 may not create child pid 1001.  It may
>create child pid 27.
>
>It may still not be feasible to use cygwin pids as windows pids
>(possibly because I don't believe that pid 1 is special to windows) but
>I thought I'd give this a try anyway unless there is something that I'm
>missing.

In other UNIXes that I know (IRIX, Solaris), there is no garantee of pid 
ordering among parent and child process.  If parent forks several children 
that fork too asynchronously, then I don't see any way of getting monotonic 
ordering.
I think that any program that would rely on monotonic pids would be 
intrinsically unstable and should be fixed instead.

Functions that map PIDs between Windows and Cygwin would be useful; e.g.,
getWindowsPID(CygwinPID) and getCygwinPID(WindowsPID).


André Bleau, ing., analyste
email: bleau at courriel dot polymtl dot ca
(Fight SPAM: encode your email-address)

Département de génie électrique et         Electric Engineering and
de génie informatique                      Computer Engineering department
École Polytechnique de Montréal            Montreal Polytechnic School


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

RE: Extending cygwin's process table

[Tony Arnold]

Chris,

> I am planning on revamping cygwin's process table for version 1.1.4.
> I hope to make process creation a little faster and to also allow many
> more cygwin processes.
>
> I'm also toying with trying to more closely tie cygwin pids to windows
> pids.

Does this mean we could get ps to report the Windows processes as well as
the cygwin ones? Also for kill to work on Windows processes as well as
cygwin ones, or is this asking too much?

Regards,
Tony.
--
Tony Arnold, Head of Science and Engineering Support Unit,
University of Manchester. Tel: +44 161 275 6093, Fax: +44 161 275 6071
E-mail: tony.arnold@man.ac.uk, Home: http://www.man.ac.uk/Tony.Arnold


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

RE: Extending cygwin's process table

[Mark Weaver]

Isn't pid creation inherently non-monotonic anyway due to multitasking
considerations, i.e.

1.	X w/pid 100 creates Y w/pid 101
2.	A w/pid 2 creates B w/pid 102
3.	Y w/pid 101 creates Z w/pid 103

...so anything that relies on monotonicity just won't be robust.  Just my
2p's worth!

Mark



-----Original Message-----
From: cygwin-owner@sources.redhat.com
[ mailto:cygwin-owner@sources.redhat.com]On Behalf Of Noel L Yap
Sent: Wednesday, July 19, 2000 2:05 PM
To: cygwin@sources.redhat.com
Subject: Re: Extending cygwin's process table






cgf@cygnus.com on 2000.07.18 23:43:19
>I'm also toying with trying to more closely tie cygwin pids to windows
>pids.

IMHO, this'd be great.

>Is anyone going to be bothered if pid creation is not monotonic?  By
>that I mean, parent pid 1000 may not create child pid 1001.  It may
>create child pid 27.

I don't think anything should be relying on this behaviour since it's not
always
satisfied (ie when ppid is near the max pid allowed).

>It may still not be feasible to use cygwin pids as windows pids
>(possibly because I don't believe that pid 1 is special to windows) but
>I thought I'd give this a try anyway unless there is something that I'm
>missing.

Yeah, I'm not sure if it's possible, but it's worth a shot (unless someone
out
there knows for sure that it's not possible).

Noel




This communication is for informational purposes only.  It is not intended
as
an offer or solicitation for the purchase or sale of any financial
instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.


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


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

Re: Extending cygwin's process table

[Noel L Yap]

cgf@cygnus.com on 2000.07.18 23:43:19
>I'm also toying with trying to more closely tie cygwin pids to windows
>pids.

IMHO, this'd be great.

>Is anyone going to be bothered if pid creation is not monotonic?  By
>that I mean, parent pid 1000 may not create child pid 1001.  It may
>create child pid 27.

I don't think anything should be relying on this behaviour since it's not always
satisfied (ie when ppid is near the max pid allowed).

>It may still not be feasible to use cygwin pids as windows pids
>(possibly because I don't believe that pid 1 is special to windows) but
>I thought I'd give this a try anyway unless there is something that I'm
>missing.

Yeah, I'm not sure if it's possible, but it's worth a shot (unless someone out
there knows for sure that it's not possible).

Noel




This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.


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

Extending cygwin's process table

[Chris Faylor]

I am planning on revamping cygwin's process table for version 1.1.4.
I hope to make process creation a little faster and to also allow many
more cygwin processes.

I'm also toying with trying to more closely tie cygwin pids to windows
pids.

Is anyone going to be bothered if pid creation is not monotonic?  By
that I mean, parent pid 1000 may not create child pid 1001.  It may
create child pid 27.

It may still not be feasible to use cygwin pids as windows pids
(possibly because I don't believe that pid 1 is special to windows) but
I thought I'd give this a try anyway unless there is something that I'm
missing.

cgf

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