on MS-Windows.
As noted in the MS documentation, WaitForMultipleObjects can wait on
- a maximum of MAXIMUM_WAIT_OBJECTS (64) objects. Due to this
+ a maximum of MAXIMUM_WAIT_OBJECTS (64) objects. Due to this
limitation, earlier versions of Emacs (at least 30) could only
support up to 32 subprocesses or network connections.
The documentation suggests using multiple threads or a thread pool to
- wait on a larger number of objects. With Windows 2000, Microsoft has
+ wait on a larger number of objects. With Windows 2000, Microsoft has
added new thread pooling functions to make thread creation,
destruction, and general management easier:
However, since the system thread pool in versions prior to Windows 7
does not support adjusting thread stack sizes by calling
SetThreadpoolStackInformation, using a large number of threads may
- consume a lot of address space. This can have a significant impact on
- the limited 2GB address space available on 32-bit systems. To avoid
+ consume a lot of address space. This can have a significant impact on
+ the limited 2GB address space available on 32-bit systems. To avoid
this issue on Windows Vista and earlier systems and make the code as
generic as possible, a simple waiting thread pool is manually
implemented here.
The waiting thread pool contains a maximum of 32 threads, with each
thread capable of waiting on up to 63 objects (one object is reserved
- for communication with the main thread). Combined with the main
+ for communication with the main thread). Combined with the main
thread's WaitForMultipleObjects call, this implementation supports
- waiting on a maximum of 2048 objects. Since Windows only supports
+ waiting on a maximum of 2048 objects. Since Windows only supports
creating subprocesses using 'pipe method, this allows Emacs to create
- a maximum of approximately 1024 subprocesses. This limit is close to
+ a maximum of approximately 1024 subprocesses. This limit is close to
the number of subprocesses that can be created using the 'pty method
on Linux when the default FD_SETSIZE is 1024.
they enter an infinite loop, waiting for an event to trigger and
begin their WaitForMultipleObjects tasks, thereby eliminating the
additional time and power consumption associated with frequently
- creating and destroying threads. If a thread is not triggered after a
+ creating and destroying threads. If a thread is not triggered after a
certain number of sys_select calls, it can be terminated to free up
resources. */
/* The values returned by WaitForMultipleObjects, WAIT_ABANDONED_0
(0x80) and WAIT_TIMEOUT (0x102), are less than 2048 (0x800), so
- define new constants to replace them. 'WFO' prefix stands for
+ define new constants to replace them. 'WFO' prefix stands for
'WaitForObjects'. */
#define WFO_ABANDONED 0x10000
#define WFO_TIMEOUT 0x20002
#define WFO_MAX_WAIT FD_SETSIZE
/* When debugging, use SetThreadDescription to provide additional
- debugging information. They are already defined in w32fns.c. */
+ debugging information. They are already defined in w32fns.c. */
typedef BOOL (WINAPI *IsDebuggerPresent_Proc) (void);
-typedef HRESULT (WINAPI *SetThreadDescription_Proc)
- (HANDLE hThread, PCWSTR lpThreadDescription);
+typedef HRESULT (WINAPI *SetThreadDescription_Proc) (HANDLE, PCWSTR);
extern IsDebuggerPresent_Proc is_debugger_present;
extern SetThreadDescription_Proc set_thread_description;
HANDLE wait_ready;
/* pHandles and nCount are part of the WaitForMultipleObjects
parameters, specifying the array of objects to wait on and the
- number of objects. bWaitAll and dwMilliseconds are not needed. */
+ number of objects. bWaitAll and dwMilliseconds are not needed. */
HANDLE *pHandles;
int nCount;
/* The return value of the thread's call to WaitForMultipleObjects. */
static wait_objects_pool wait_pool;
static wait_objects_info wait_info;
-/* Thread proc for worker threads waiting on objects. Each thread is
+/* Thread proc for worker threads waiting on objects. Each thread is
normally blocked until woken by the main thread to wait on objects.
When the wait completes, wait_ready is signaled to wake up the main
thread and the thread blocks itself again.
The worker thread needs to wait for the timeout event from the main
- thread. When timeout_event is signaled by the main thread, it will
- end the current wait and start the next round. Similarly, threads
+ thread. When timeout_event is signaled by the main thread, it will
+ end the current wait and start the next round. Similarly, threads
also need to wait for an quit event, which usually occurs when the
thread has not been used for a certain period of time. */
static DWORD WINAPI
/* Determine the grouping based on the given wait objects and assign
them to the worker threads to begin waiting, creating new worker
- threads if necessary. The function also performs initialization of
+ threads if necessary. The function also performs initialization of
some static resources. */
static int
start_wait_objects (wait_objects_info *p,
/* Set init_flag. */
wait_pool.init_flag = TRUE;
}
- /* Check if all threads in the thread pool are working properly. If
+ /* Check if all threads in the thread pool are working properly. If
any thread has exited, exit immediately. */
for (int i = 0; i < wait_pool.count; i++)
{
/* The MS documentation suggests that callers should call the
GetExitCodeThread function only after the thread has been
- confirmed to have exited. Use the WaitForSingleObject with a
+ confirmed to have exited. Use the WaitForSingleObject with a
wait duration of zero to determine whether a thread has
exited. */
DWORD res = WaitForSingleObject (wait_pool.wocs[i].thread, 0);
else if (res == WAIT_OBJECT_0)
{
/* The last-error code is kept in thread local storage so that
- multiple threads do not overwrite each other's values. Pass
+ multiple threads do not overwrite each other's values. Pass
the error by using SetLastError to set the error value. */
SetLastError (wait_pool.wocs[i].errcode);
return WFO_FAILED;
}
/* Calculate the required number of threads and the number of objects
the main thread needs to wait for based on the number of objects to
- be waited on. To avoid increasing the number of threads for a small
+ be waited on. To avoid increasing the number of threads for a small
increase in the number of objects (e.g., using two threads for 65
objects), the following calculation allows the main thread's array
to hold up to 32 wait objects, excluding the thread event
- handles. With this approach, the minimum number of wait objects for
+ handles. With this approach, the minimum number of wait objects for
the worker threads is 32, and it allows a maximum of 63 * 32 + 32 =
2048 objects to be waited on.
The number of child process in Emacs is limited by MAX_CHILDREN,
- which is half of MAXDESC (FD_SETSIZE). When FD_SETSIZE is set to
+ which is half of MAXDESC (FD_SETSIZE). When FD_SETSIZE is set to
2048, a maximum of 1024 child processes and network/serial are
- allowed. Compared to network/serial, the process handles of child
+ allowed. Compared to network/serial, the process handles of child
processes are also waited on, which is why only a maximum of 1024
child processes can be created.
When there are 1024 child processes, the main thread needs to wait
for 64 objects, which seems to exceed the 63 allowed by
- MsgWaitForMultipleObjects. However, due to the influence of
+ MsgWaitForMultipleObjects. However, due to the influence of
emacs_pipe, a maximum of only 1021 child processes can be created,
so the number of elements in the main thread's wait array will not
- exceed 63. The explanation is as follows:
+ exceed 63. The explanation is as follows:
. emacs_pipe calls the pipe2 function located in w32.c.
. pipe2 makes sure that file descriptors return by _pipe less than
MAXDESC (2048), Therefore, the range of available file descriptor
values is from 3 to 2047 (0, 1, 2 for stdin, stdout and
- stderr). Since pipe file descriptors are opened in pairs, the
+ stderr). Since pipe file descriptors are opened in pairs, the
actual range is from 3 to 2046, meaning there are 2044 available
file descriptors.
. When create_process creates a process using the 'pipe' method, it
- creates two pipes, one for reading and one for writing. It then
+ creates two pipes, one for reading and one for writing. It then
closes one file descriptor for each pipe, as each pipe is only
- used for reading or writing. This results in 4 file descriptors
+ used for reading or writing. This results in 4 file descriptors
being used initially for each process creation, and then 2 are
- released. When only 2 empty slots remain, no new child processes
+ released. When only 2 empty slots remain, no new child processes
can be created.
. In the end, we can use 2042 file descriptors, which allows for
1021 child processes. */
objects in the main thread's array exceeds 32. */
p->nt = 1 + (nCount - 33) / 63;
/* The number of objects the main thread needs to wait for is the
- required number of threads plus the remaining objects. If the
+ required number of threads plus the remaining objects. If the
existing threads are sufficient to wait for all the objects, then
nh is the number of threads. */
p->nh = (p->nt * 63 >= nCount) ? p->nt : (p->nt + nCount - p->nt * 63);
if (p->nh != p->nt)
memcpy (p->hs + p->nt, lpHandles + p->nt * 63,
sizeof (HANDLE) * (nCount - p->nt * 63));
- /* Set the pHandles and nCount parameters for each thread. Since the
+ /* Set the pHandles and nCount parameters for each thread. Since the
waiting task is relatively simple, we do not need a dedicated
- task queue mechanism. We can simply wait for the corresponding
+ task queue mechanism. We can simply wait for the corresponding
objects in the order of the thread context array wait_pool.wocs. */
for (int i = 0; i < p->nt; i++)
{
/* If it is the last thread and the thread is sufficient to wait
all the objects, then the count needs to be calculated;
otherwise, it will be 63. */
- int count = (i == p->nt - 1)
- ? (p->nt == p->nh) ? (nCount - i * 63) : 63 : 63;
+ int count = ((i == p->nt - 1)
+ ? ((p->nt == p->nh)
+ ? (nCount - i * 63) : 63)
+ : 63);
wait_pool.wocs[i].nCount = count;
wait_pool.wocs[i].pHandles = lpHandles + i * 63;
}
/* Set call_count and errcode to ZERO. */
ctx->call_count = 0;
ctx->errcode = 0;
- /* Creating new worker threads. Please refer to the comment in
+ /* Creating new worker threads. Please refer to the comment in
w32proc.c within the new_child function, where the
reader_thread thread is created, to understand why these
parameters are needed. */
/* CreateThread failed. */
if (!ctx->thread)
return WFO_FAILED;
- /* Set Thread Description information. This may be handy with
+ /* Set Thread Description information. This may be handy with
debugging. */
if (is_debugger_present && is_debugger_present ()
&& set_thread_description)
{
p->hs[i] = wait_pool.wocs[i].wait_ready;
/* Reset the wait_ready event and set wait_start event for threads
- that are not newly created. Newly created threads start
+ that are not newly created. Newly created threads start
execution immediately. */
if (i < orig_thread_count)
{
/* Set timeout_event to tell all worker threads stop waiting. */
if (!SetEvent (wait_pool.timeout_event))
return WFO_FAILED;
- /* Wait for all the used worker threads to signal wait_ready. This
+ /* Wait for all the used worker threads to signal wait_ready. This
typically takes no more than a few dozen microseconds, so a
timeout indicates that an error has occurred. */
DWORD result = WaitForMultipleObjects (p->nt, p->hs, TRUE, 20);
if (result == WAIT_FAILED || result == WAIT_ABANDONED)
return WFO_FAILED;
- /* Timeout means there exists a thread exit abnormally. Since the
+ /* Timeout means there exists a thread exit abnormally. Since the
WAIT_FAILED error in the worker threads signals wait_ready, this
can only be an error occurring when the worker threads are waiting
for curr_start and wait_quit. */
return WFO_FAILED;
}
/* Even if the wait succeeds, there is still a possibility that some
- wait_ready might be signaled by a WAIT_FAILED error. To determine
+ wait_ready might be signaled by a WAIT_FAILED error. To determine
if no WAIT_FAILED error occurred, check the errcode of all threads. */
for (int i = 0; i < p->nt; i++)
{
else if (result == WAIT_FAILED)
return WFO_FAILED;
/* It seems that all the wait objects are just process handles and
- event handles. WAIT_ABANDONED may not occur, but let's just
+ event handles. WAIT_ABANDONED may not occur, but let's just
handle it here. */
else if (result >= WAIT_ABANDONED_0
&& result < p->nh + WAIT_ABANDONED_0)
{
result -= WAIT_ABANDONED_0;
- /* The event object wait_ready is not mutex object. This is
+ /* The event object wait_ready is not mutex object. This is
unlikely to happen... */
if (result < p->nt)
return WFO_FAILED;
/* There are 62 * nt objects before the objects in the main
- thread. Each thread can wait for 63 objects, and each
+ thread. Each thread can wait for 63 objects, and each
thread's wait_ready occupies one position in the main thread
- array. Therefore, the index of the waiting object in the main
+ array. Therefore, the index of the waiting object in the main
thread array should be incremented by (63 - 1) multiplied by
- the number of worker threads. We add WFO_ABANDONED to
+ the number of worker threads. We add WFO_ABANDONED to
distinguish it from normal object index. */
result = result + 62 * p->nt + WFO_ABANDONED;
}
and the number of worker threads is equal to the number of
wait objects for the main thread, it indicates that the main
thread is using MsgWaitForMultipleObjects and that there are
- no wait objects in the main thread's array. We should return
+ no wait objects in the main thread's array. We should return
the total number of wait objects to indicate that a message
was received during the wait. */
if (p->nt == p->nh)
else
{
DWORD t_result = wait_pool.wocs[idx].result;
- /* WAIT_FAILED or WAIT_TIMEOUT. Since the wait time in the
+ /* WAIT_FAILED or WAIT_TIMEOUT. Since the wait time in the
worker thread is set to INFINITE, WAIT_TIMEOUT should not
occur. */
if (t_result == WAIT_FAILED || t_result == WAIT_TIMEOUT)
SetLastError (wait_pool.wocs[idx].errcode);
return WFO_FAILED;
}
- /* Abandoned. Compared to the waiting objects in the main
+ /* Abandoned. Compared to the waiting objects in the main
thread's array, the index in the worker threads needs to be
incremented by 63 times the number of preceding threads,
rather than 62. */
else if (t_result >= WAIT_ABANDONED_0
&& t_result < wait_pool.wocs[idx].nCount
+ WAIT_ABANDONED_0)
- result = idx * 63 + t_result
- + WFO_ABANDONED - WAIT_ABANDONED_0;
+ result = (idx * 63 + t_result
+ + WFO_ABANDONED - WAIT_ABANDONED_0);
/* The worker thread is signaled by timeout_event, but at this
point, timeout_event has not yet been signaled. */
else if (t_result == wait_pool.wocs[idx].nCount + WAIT_OBJECT_0)
shrink_wait_pool (void)
{
wait_pool.main_thread_waits++;
- /* Check the thread every 64 Wait call. 64 is just a value that might
+ /* Check the thread every 64 Wait call. 64 is just a value that might
be reasonably suitable. */
if (wait_pool.main_thread_waits <= 64)
return 0;
}
/* Exit all worker threads and release the start and timeout
- handles. This function is called when exiting Emacs. */
+ handles. This function is called when exiting Emacs. */
void
free_wait_pool (void)
{
CloseHandle (wait_pool.wocs[i].wait_start);
CloseHandle (wait_pool.wocs[i].wait_ready);
}
- /* Wait all workder threads exit. Stop if failed. */
+ /* Wait all worker threads exit. Stop if failed. */
for (int i = 0; i < wait_pool.count; i++)
{
if (WaitForSingleObject (wait_pool.wocs[i].thread, 1)
}
/* Replacement of WaitForMultipleObjects, with the bWaitAll parameter
- removed. The function's return values are as follows:
+ removed. The function's return values are as follows:
[0 ~ nCount-1], the return value indicates the lpHandles array
index of the object that satisfied the wait.
[WFO_TIMEOUT], The time-out interval elapsed.
- [WFO_FAILED], The function has failed. To get extended error
+ [WFO_FAILED], The function has failed. To get extended error
information, call GetLastError. */
static DWORD
wait_for_objects (DWORD nCount, HANDLE *lpHandles,
FALSE, dwMilliseconds);
/* If the main thread wait times out, call WaitForMultipleObjects
again with zero time-out interval to check if any objects have
- completed. The default clock resolution of Windows is 64 Hz. If a
+ completed. The default clock resolution of Windows is 64 Hz. If a
time less than 15.625ms is specified, the waiting time may be
longer than the specified time, and some objects that were not
completed in the previous call may now be completed. */
}
/* Replacement of MsgWaitForMultipleObjects, with the bWaitAll and
- dwWakeMask parameters removed. The function's return values are as
+ dwWakeMask parameters removed. The function's return values are as
follows:
[0 ~ nCount-1], the return value indicates the lpHandles array
[WFO_TIMEOUT], The time-out interval elapsed.
- [WFO_FAILED], The function has failed. To get extended error
+ [WFO_FAILED], The function has failed. To get extended error
information, call GetLastError. */
static DWORD
msg_wait_for_objects (DWORD nCount, HANDLE *lpHandles,
return WFO_TIMEOUT;
/* The return value of MsgWaitForMultipleObjects can be
WAIT_OBJECT_0 + nCount, indicating that a message was
- received. So use (<=) rather than (<) here. */
+ received. So use (<=) rather than (<) here. */
else if (res >= WAIT_OBJECT_0
&& res <= WAIT_OBJECT_0 + nCount)
return res - WAIT_OBJECT_0;
&& res < WAIT_OBJECT_0 + count)
return offset + res - WAIT_OBJECT_0;
/* When a message is received during the wait, return nCount
- directly. This is the distinction that needs to be made
+ directly. This is the distinction that needs to be made
compared to wait_for_objects. */
else if (res == WAIT_OBJECT_0 + count)
return nCount;
{
int i;
- /* Should not be deleting a child that is still needed. */
+ /* Should not be deleting a child that is still needed. */
for (i = 0; i < MAXDESC; i++)
if (fd_info[i].cp == cp)
emacs_abort ();
}
}
-/* Thread proc for child process and socket reader threads. Each thread
+/* Thread proc for child process and socket reader threads. Each thread
is normally blocked until woken by select() to check for input by
reading one char. When the read completes, char_avail is signaled
- to wake up the select emulator and the thread blocks itself again. */
+ to wake up the select emulator and the thread blocks itself again. */
static DWORD WINAPI
reader_thread (void *arg)
{
break;
/* The name char_avail is a misnomer - it really just means the
- read-ahead has completed, whether successfully or not. */
+ read-ahead has completed, whether successfully or not. */
if (!SetEvent (cp->char_avail))
{
DebPrint (("reader_thread.SetEvent(0x%x) failed with %lu for fd %ld (PID %d)\n",
/* CreateProcess handles batch files as exe specially. This special
handling fails when both the batch file and arguments are quoted.
- We pass NULL as exe to avoid the special handling. */
+ We pass NULL as exe to avoid the special handling. */
if (exe && cmdline[0] == '"' &&
(ext = strrchr (exe, '.')) &&
(xstrcasecmp (ext, ".bat") == 0
if (dont_wait)
timeout_ms = 0;
else
- timeout_ms = 1000; /* check for quit about once a second. */
+ timeout_ms = 1000; /* Check for quit about once a second. */
do
{
}
/* Return pointer to section header for section containing the given
- relative virtual address. */
+ relative virtual address. */
IMAGE_SECTION_HEADER *
rva_to_section (DWORD_PTR rva, IMAGE_NT_HEADERS * nt_header)
{
projects / emacs.git / commitdiff