On Dec  4 12:51, Christopher Faylor wrote:
> On Wed, Dec 04, 2013 at 06:23:24PM +0100, Corinna Vinschen wrote:
> >On Dec  4 12:00, Christopher Faylor wrote:
> >> On Wed, Dec 04, 2013 at 01:04:08PM +0100, Corinna Vinschen wrote:
> >> >On Dec  4 12:36, Corinna Vinschen wrote:
> >> >> On Dec  4 10:32, Corinna Vinschen wrote:
> >> >> > Hi guys,
> >> >> > [...etc...]
> >> >> > The problem is still present in the current sources.
> >> >> > [...]
> >> >
> >> >Ouch, ouch, ouch!  I tested the wrong DLL.  Actually current CVS fixes
> >> >this problem.  Duh.  Sorry for the confusion.
> >> >
> >> >One question, though.  Assuming start is == size, then the current code
> >> >in CVS extends the fd table by only 1.  If that happens often, the
> >> >current code would have to call ccalloc/memcpy/cfree a lot.  Wouldn't
> >> >it in fact be better to extend always by at least NOFILE_INCR, and to
> >> >extend by (1 + start - size) only if start is > size + NOFILE_INCR?
> >> >Something like
> >> >
> >> >  size_t extendby = (start >= size + NOFILE_INCR) ? 1 + start - size : NOFILE_INCR;
> >> >
> >> >?
> >> >
> >> >Sorry again.  Fortunately it's my WJM week...
> >> 
> >> I don't think it is a common occurrence for start >= size.  It is
> >> usually done when something like bash dup2's stdin/stdout/stderr to a
> >> high fd.  Howeer, I'll check in something which guarantees that there is
> >> always a NOFILE_INCR entries free after start.
> >
> >That might be helpful.  Tcsh, for instance, always dup's it's std
> >descriptors to the new fds 15-19.  If it does so in this order, it would
> >have to call extend 5 times.
> 
> dtable.h:#define NOFILE_INCR    32
> 
> It shouldn't extend in that scenario.  The table starts with 32
> elements.

Right.  I just thought it's a good example.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat