Date:	Sun, 19 Aug 2001 09:08:14 +0300
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<7458-Sun19Aug2001090813+0300-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<10108190425.AA12230@clio.rice.edu> (sandmann@clio.rice.edu)
Subject:	Re: Selector exhaustion code update
References:	<10108190425 DOT AA12230 AT clio DOT rice DOT edu>
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

> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Sat, 18 Aug 2001 23:25:18 -0500 (CDT)
> 
> Included below is my version of the selector code based on Andris code
> and my test code.

Thanks!

> Comments?  Since the new code is rather conservative, I didn't see
> a reason to disable it.

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.

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?

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.

- Raw text -