aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorEli Zaretskii2015-11-03 18:17:06 +0200
committerEli Zaretskii2015-11-03 18:17:06 +0200
commite7bde34e939451d87fb42a36195086bdbe48b5e1 (patch)
treef0f2d8396a187740aeaa4706f8cdb84f81722418
parent470e3028d8a741d97349faa8fdeb148d913a49d0 (diff)
downloademacs-old-branches/concurrency.tar.gz
emacs-old-branches/concurrency.zip
; * src/systhread.c [WINDOWSNT]: Fix typos in comments.old-branches/concurrency
-rw-r--r--src/systhread.c10
1 files changed, 5 insertions, 5 deletions
diff --git a/src/systhread.c b/src/systhread.c
index bde0f027e78..c11e0247886 100644
--- a/src/systhread.c
+++ b/src/systhread.c
@@ -207,7 +207,7 @@ uintptr_t _beginthread (void (__cdecl *)(void *), unsigned, void *);
207 207
208/* Mutexes are implemented as critical sections, because they are 208/* Mutexes are implemented as critical sections, because they are
209 faster than Windows mutex objects (implemented in userspace), and 209 faster than Windows mutex objects (implemented in userspace), and
210 satisfy the requirements, since we only needto synchronize within a 210 satisfy the requirements, since we only need to synchronize within a
211 single process. */ 211 single process. */
212void 212void
213sys_mutex_init (sys_mutex_t *mutex) 213sys_mutex_init (sys_mutex_t *mutex)
@@ -234,7 +234,7 @@ sys_mutex_destroy (sys_mutex_t *mutex)
234{ 234{
235 /* FIXME: According to MSDN, deleting a critical session that is 235 /* FIXME: According to MSDN, deleting a critical session that is
236 owned by a thread leaves the other threads waiting for the 236 owned by a thread leaves the other threads waiting for the
237 critical session in an undefined state. Posix docs seems to say 237 critical session in an undefined state. Posix docs seem to say
238 the same about pthread_mutex_destroy. Do we need to protect 238 the same about pthread_mutex_destroy. Do we need to protect
239 against such calamities? */ 239 against such calamities? */
240 DeleteCriticalSection ((LPCRITICAL_SECTION)mutex); 240 DeleteCriticalSection ((LPCRITICAL_SECTION)mutex);
@@ -354,6 +354,8 @@ sys_thread_equal (sys_thread_t one, sys_thread_t two)
354 354
355static thread_creation_function *thread_start_address; 355static thread_creation_function *thread_start_address;
356 356
357/* _beginthread wants a void function, while we are passed a function
358 that returns a pointer. So we use a wrapper. */
357static void 359static void
358w32_beginthread_wrapper (void *arg) 360w32_beginthread_wrapper (void *arg)
359{ 361{
@@ -369,12 +371,10 @@ sys_thread_create (sys_thread_t *thread_ptr, const char *name,
369 the main program. On GNU/Linux, it seems like the stack is 2MB 371 the main program. On GNU/Linux, it seems like the stack is 2MB
370 by default, overridden by RLIMIT_STACK at program start time. 372 by default, overridden by RLIMIT_STACK at program start time.
371 Not sure what to do with this. See also the comment in 373 Not sure what to do with this. See also the comment in
372 w32proc"new_child. */ 374 w32proc.c:new_child. */
373 const unsigned stack_size = 0; 375 const unsigned stack_size = 0;
374 uintptr_t thandle; 376 uintptr_t thandle;
375 377
376 /* _beginthread wants a void function, while we are passed a
377 function that returns a pointer. So we use a wrapper. */
378 thread_start_address = func; 378 thread_start_address = func;
379 379
380 /* We use _beginthread rather than CreateThread because the former 380 /* We use _beginthread rather than CreateThread because the former