[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emacs-diffs] concurrency e7bde34: ; * src/systhread.c [WINDOWSNT]: Fix
From: |
Eli Zaretskii |
Subject: |
[Emacs-diffs] concurrency e7bde34: ; * src/systhread.c [WINDOWSNT]: Fix typos in comments. |
Date: |
Tue, 03 Nov 2015 16:18:10 +0000 |
branch: concurrency
commit e7bde34e939451d87fb42a36195086bdbe48b5e1
Author: Eli Zaretskii <address@hidden>
Commit: Eli Zaretskii <address@hidden>
; * src/systhread.c [WINDOWSNT]: Fix typos in comments.
---
src/systhread.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/systhread.c b/src/systhread.c
index bde0f02..c11e024 100644
--- a/src/systhread.c
+++ b/src/systhread.c
@@ -207,7 +207,7 @@ uintptr_t _beginthread (void (__cdecl *)(void *), unsigned,
void *);
/* Mutexes are implemented as critical sections, because they are
faster than Windows mutex objects (implemented in userspace), and
- satisfy the requirements, since we only needto synchronize within a
+ satisfy the requirements, since we only need to synchronize within a
single process. */
void
sys_mutex_init (sys_mutex_t *mutex)
@@ -234,7 +234,7 @@ sys_mutex_destroy (sys_mutex_t *mutex)
{
/* FIXME: According to MSDN, deleting a critical session that is
owned by a thread leaves the other threads waiting for the
- critical session in an undefined state. Posix docs seems to say
+ critical session in an undefined state. Posix docs seem to say
the same about pthread_mutex_destroy. Do we need to protect
against such calamities? */
DeleteCriticalSection ((LPCRITICAL_SECTION)mutex);
@@ -354,6 +354,8 @@ sys_thread_equal (sys_thread_t one, sys_thread_t two)
static thread_creation_function *thread_start_address;
+/* _beginthread wants a void function, while we are passed a function
+ that returns a pointer. So we use a wrapper. */
static void
w32_beginthread_wrapper (void *arg)
{
@@ -369,12 +371,10 @@ sys_thread_create (sys_thread_t *thread_ptr, const char
*name,
the main program. On GNU/Linux, it seems like the stack is 2MB
by default, overridden by RLIMIT_STACK at program start time.
Not sure what to do with this. See also the comment in
- w32proc"new_child. */
+ w32proc.c:new_child. */
const unsigned stack_size = 0;
uintptr_t thandle;
- /* _beginthread wants a void function, while we are passed a
- function that returns a pointer. So we use a wrapper. */
thread_start_address = func;
/* We use _beginthread rather than CreateThread because the former
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Emacs-diffs] concurrency e7bde34: ; * src/systhread.c [WINDOWSNT]: Fix typos in comments.,
Eli Zaretskii <=