Re: Increase FD_SETSIZE in w32.h to allow more than 32 (actually 29) subprocesses

[Eli Zaretskii]

> From: "Yue Yi" <include_yy@qq.com>
> Cc: "emacs-devel" <emacs-devel@gnu.org>
> Date: Thu, 30 Jan 2025 15:38:26 +0800
> 
> > > In this implementation, when there are a large number of child processes
> > > (around 1000), the maximum call time for accept-process-output does not
> > > exceed 100 microseconds. However, there might still be room for
> > > improvement.
> > 
> > AFAIR, you said that starting new threads each time meant the timing
> > was 160 microseconds (vs just 2 usec without threads)?  If so, the
> > improvement due to using thread pool is a bit disappointing, no?  If
> > the time cannot be reduced to, say, 25 usec (which is already 10 times
> > the current performance), then maybe the additional complexities of
> > using a thread pool are not justified, and we should live with the
> > slower subprocess responses when there's more than 30 of them?
> 
> Without using a thread pool, there is a significant time jump when
> transitioning from not needing a thread to needing one: from 2 usec to
> 160 usec, as I described earlier. In this case, if threads are created
> only at the time of the call, the time would be an astonishing 4 ms when
> we have about 1000 subprocesses.
> 
> After using the thread pool, the transition from not needing a thread to
> needing one changes from 2 usec to 12 usec. I mean, after using a
> thread pool, even when we have many subprocesses running simultaneously
> (around 1000 subprocesses correspond to needing about 32 threads), call
> time of `accept-process-output' does not exceed 100 microseconds.

Ah, okay, thanks.  So then using a thread pool is indeed justified.

> > You will find many examples of using these techniques in w32*.c source
> > files, and we can discuss what to do in specific situations you
> > encounter as part of working on this feature.
> 
> Thanks, see you next month :)

Thanks in advance.