delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/03/23/12:00:11

From: cgf AT bbc DOT com (Christopher Faylor)
Subject: Re: Process ID allocation methods
23 Mar 1998 12:00:11 -0800 :
Message-ID: <Eq8t53.D3u.cygnus.cygwin32.developers@bbc.com>
References: <01BD557C DOT A9B52A90 AT sos>
Reply-To: cgf AT bbc DOT com
To: cygwin32-developers AT cygnus DOT com

In article <01BD557C DOT A9B52A90 AT sos>,
Sergey Okhapkin  <sos AT buggy DOT prospect DOT com DOT ru> wrote:
>Geoffrey Noer wrote:
>> > Have there been complaints about the pids wrapping too fast or have 
>people
>> > been running out of pids?
>>
>> People have definitely been running out of pids.  I see the occasional
>> "fork: no more processes" message in peoples' complaints to the list.
>
>I'm sure, the message was not because of process table overflow. Did you 
>ever try to run more than 100 processes on windows nt?-) When running 
>configure/make etc I never saw more than 20-30 simultaneous cygwin 
>processes running.

As I've already said, I agree with this.

Also, the code in allocate_pid is a little inefficient right now.  When
you hit the end of the list of pids, it will do a brute force scan through
the pid table attempting to clean up processes that have abnormally terminated.
It determines if a pid has exited via some windows calls which have got
to be more expensive than just checking an in_use bit.  It also seems that
there is a possibility that if the last pid in the list is used, then
next_pid will never wrap, leaving cygwin in a permanent "out of pids" state.

My version of this code only did the "brute force" thing as a last
resort if no pids were available, which should be a very rare event.
I think it dealt successfully with the last pid being allocated, too.
-- 
http://www.bbc.com/	cgf AT bbc DOT com			"Strange how unreal
VMS=>UNIX Solutions	Boston Business Computing	 the real can be."

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019