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. cgf