From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10108191659.AA16921@clio.rice.edu>
Subject: Re: Selector exhaustion code update
To: eliz AT is DOT elta DOT co DOT il
Date: Sun, 19 Aug 2001 11:59:32 -0500 (CDT)
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <7458-Sun19Aug2001090813+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Aug 19, 2001 09:08:14 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> I have only one comment:
> 
> > +     if (workaround_descriptor_leaks)
> > +       desc_map = (char *)malloc(how_deep);
> 
> I'm nervous about calling malloc at that stage.  We are past the point
> where the transfer buffer can be freely used by system calls (since
> some of the data for invoking the child program is already in the
> transfer buffer).  Although I know malloc currently doesn't use the
> transfer buffer, I'm still nervous.  In addition, calling malloc might
> cause trickery with our selectors which could potentially disrupt the
> (purely phenomenological) idea behind this work-around.

The transfer buffer is still free at this point - I've put gobs of
printf's in at this stage to check things.  Andris restructured where
this is done further away from the TB mucking.  

> I guess the upshot of this is that if it's possible to use a static
> buffer, I'd prefer that.  I realize that there could be up to 8KB in
> that buffer, but v2.04 is going to bloat executables anyway, due to
> support for symlinks.  If 8KB is deemed too much nonetheless, perhaps
> we could have a static buffer for some small size that is sufficient
> in most cases, and switch to a malloc'ed buffer if it's not enough?

The buffer can come from the stack, so we make it 8192 fixed on the 
stack or do something more sophisticated.  

> Also, maybe the comments in the code could be made more explicit about
> things that are done by each of the options, to avoid maintenance
> problems in the future.

Any comments are appreciated, but I'll try to fill out some details.