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

[Cecilio Pardo]

On 25/01/2025 13:55, Eli Zaretskii wrote:

> Since the maximum size of these is known in advance, and fixed by the
> implementation, I think it would be better to avoid the constant
> allocation and deallocation of these arrays, and instead have static
> arrays of their maximum size.


> +static void
> +CleanupWaitForMultipleObjectsInfo (WaitForMultipleObjectsInfo *p)
> +{
> +  SetEvent (p->hEndEvent);
> +  WaitForMultipleObjects(p->nThread, p->hObjects, TRUE, INFINITE);
> +
> +  xfree (p->hObjects);
> +  xfree (p->pHandles);
> +  xfree (p->pParams);
> +  CloseHandle (p->hEndEvent);
> +  for (int i = 0; i < p->nThread; i++)
> +    CloseHandle (p->hObjects[i]);
> +  return;
> +}

I agree with using static data, but in case you keep the allocations, 
close the handles in hObjects before freeing hObjects.

> IIUC, this will cause us starting 2 threads when we need to start 65
> processes.  Wouldn't it be better to use just one thread, and wait for
> the other processes as we do now using the rest of available slots in
> the wait_hnd[] array?
>
> Finally, is it known how long it takes on a modern Windows system to
> start a thread?  This could be important for assessing the impact of
> this design on the performance of sub-processes on MS-Windows.

Have you considered using the thread pool (QueueUserWorkItem) instead of 
manually creating threads?. This would make the code somewhat more 
complex. Also, threads from the pool use the default stack size, and 
that seems to be a problem here.